Dave Brasgalla has an interesting write-up on the iconography of the first Alien film and its parallels to the iconography of iOS 7. In the course of his article, he offers his take on iOS 7:

For my part, I have a very positive feeling towards iOS 7, for one main reason: it brings computer iconography firmly back around to concentrating on communication rather than illustration – function over form. This is the realm of the graphic designer, where informed decisions about composition and colour create successful, strong symbology that will outlast trends, and is applicable over multiple uses.

I think everything he writes makes sense, but I also think what he says is totally irrelevant to why most people buy and enjoy iPhones and iPads.

People don’t choose an iOS device out of respect for Apple’s adherence to formal design principles. They are only dimly aware, if at all, of the design battles being waged between people who make apps and smartphones for a living. People buy iPhones and iPads because they are the first computers that you can use without feeling stupid.

The warm, evocative design of iOS 1 through 6 made using a computer easy and fun. For many, many people, this was an entirely novel experience. Most people had only ever owned or used clunky, complicated Windows PCs for work or school. It was walking on egg shells, and it was never fun. The iPhone changed all that.

Designers with more rarified tastes may cringe at torn paper textures and green felt, but these extremes were the exceptions, not the norm. This bears repeating: the skeuomorphic excesses of iOS 1-6 were the exception, not the norm. The norm was much more nuanced. The aesthetics were focused on making things intuitive and fun:

• Notes.app Icon: On iOS 6, the Notes.app icon was a little roundrect version of a yellow legal pad. It was warm, cute, and — most importantly — easy to understand. It immediately conveyed its purpose: this is for jotting down notes. The new icon looks like nothing at all. It has been designed with strict adherence to Apple’s new formal visual rules for their app icons, but only against that metric could it be called a success. The new icon puts form before function.

• Buttons: On iOS 6, buttons had subtle gradients and borders, not as whizz-bang, but to make it abundantly clear where you were being invited to tap — just as sidewalks make it abundantly clear where you are being invited to walk. On iOS 7, it is often impossible to tell what is a button and what is not.

• Slide-to-Unlock: On iOS 1-6, the lock screen slider was composed of a sliding button and a track. It was so easy to understand that babies literally figured it out on their own. The springy physics were reminiscent of the spring-loaded locks on gym locker doors, which helped both convey the slider’s purpose and how to use it. On iOS 7, the obvious slider has been replaced by a tiny chevron on de-valued visual footing against many similarly-colored elements. There is no visual affordance for how the unlock gesture is supposed to work. The “slide to unlock” text label is still there, but a) it doesn’t specify what or where you are supposed to slide, and b) is so thin and glittery that it is often impossible to read. Try starting a turn-by-turn Maps.app session and then look at your lock screen. It’s incomprehensible.

We’ve all heard the old design adage that “form follows function.” Those of us who make apps for a living have heard it so many times that it’s easy to ignore it as trite. In reality it is very difficult to adhere to that principle. It is difficult because separating form from function is a messy exercise. It must be done delicately, and with respect for what our users think and feel.

On iOS, putting function before form is not as simple as paring down icons to a strict grid and color palette. There are functions beyond literal communication that iOS designers must balance. Making icons warm and inviting serves many deeper purposes. It builds your confidence in the device. It makes you feel in control. It sets your mind and thumbs at ease. It communicates through feeling and memory, and when done well, resonates with human experience in a way that PCs never could.

I dislike iOS 7 so strongly that I feel inclined to begin this post with a disclaimer about how much I admire Apple. Apple is my hero. They’ve always inspired me to be better at what I do, even when I was an ICU nurse. But they are not perfect. I can and should criticize their worst work when I find it — out of my admiration for their best work.

To understand the biggest design mistake Apple made in iOS 7, you have to acknowledge a fact so obvious that it can be easily overlooked: touch. The essential characteristic of iOS is touch. Skin against glass. A round, squishy, inaccurate little fat pad at the end of your finger. Unlike the PCs that iOS devices replaced, everything you do on iOS is driven by your thumb pressed directly against the screen. There is no intermediary device. Simply put, the importance of touch on iOS cannot be overstated.

Good iOS app design is obsessed with touch. Bad iOS app design takes touch for granted. We’ve all seen apps that look like they were designed by talented print designers, apps with beautiful screenshots and tasteful typography that nevertheless fall apart disgracefully as soon as you actually try to use them. These apps don’t fail for lack of talent. They fail because their designers have the wrong process. They’re beginning with aesthetics and squeezing in the interactions wherever they have room to fit. The right process moves in the opposite direction. A good iOS app designer begins with touch, and only afterwards chooses aesthetics that complement and enhance the underlying touchable structure. iOS 7 has been designed with the wrong process.

What makes something touchable?

For things that scroll or zoom, touchability means that the content under your finger moves with your touch, without any lag or jitters. iOS 7 does as good a job with this as with previous iOS versions. In some cases it does it even better, as in the new swipe-to-go-back gesture in apps like Safari and Mail, or the bouncy physics that you can see when swiping up the Control Center.

For buttons, touchability requires something different. Touchable buttons need borders. By “borders” I don’t mean outlines, (although outlines are included in my usage of the word). I mean borders in a broader sense. A button is a tappable area, clearly delineated from the un-tappable content around it by an obvious border.

Borders around buttons can be real or implied. A real border is like the roundrect shape around a “Buy” button on the App Store. An implied border is like those around the toolbar icons at the bottom of the Safari screen.

Implied borders are easy to get wrong. Care must be taken to make sure that aesthetic choices don’t obscure where one button ends and another begins. This is why iOS app designers make all toolbar icons fit into a roughly square shape. When set together in a row, adequately spaced, the eye can perceive the 44-by-44 point implied border around each button.

iOS 7’s designers have abandoned bordered buttons in favor of borderless colored text. I think this choice is unjustifiable. It is the root cause of my deep dislike for how it feels to use iOS 7. It introduces unnecessary tension and makes everything less usable than it ought to be.

Color alone simply cannot be the way to identify a button. You don’t touch a color. You touch an area. To activate a button, you must touch a spot inside of its boundary. Text floating in the middle of vast whitespace doesn’t define a boundary. Only borders define boundaries.

Compare the navigation bar buttons from the native Twitter share sheet with those from Tweetbot’s navigation bar:

In the iOS 7 share sheet, there are three text labels: Cancel, Twitter, and Post. Which of these three are buttons and which ones are not? Those of us who are lucky enough to have good vision might correctly guess that the blue ones are buttons, but what if we were color blind? Furthermore, how do we know whether or not the title doubles as a tappable button, like the title button in Tweetbot that can be used to toggle the source list?

The Tweetbot title button is obvious because it’s enclosed by obvious borders. If Tweetbot were redesigned to strictly adhere to the iOS 7 paradigm, it would be impossible to know whether or not the title was tappable. What if this fictional Tweetbot made the title blue also. Wouldn’t that actually make it harder to distinguish buttons from inert labels?

There are many other examples in iOS 7 of how the lack of borders creates a dizzying confusion. The Contacts app is a particularly strong example:

How do we know that “John” and “Appleseed” are editable? They’re not blue. They’re black, borderless, and floating some inscrutable distance from one another and from the other elements above and below them. How do we know that they are separate text fields, and not one big multiline text view? Is “Company” editable? If so, where does it’s tappable region end and the “add phone” area begin? Likewise, what about the empty region between “add phone” and “add email”? Are the cell separator lines defining a tappable boundary around the “add email” row? You’d be forgiven for assuming so, since those lines create the impression of a tall tappable row, but you’d be wrong.

I imagine that folks might argue that web page links are examples of buttons made solely from colored text. Aren’t people already familiar enough with links on the web that using the same paradigm on iOS is a simple change?

My counterargument is that web links are subject to the same visual risks as native buttons on iOS. Links can be just as confusing if not treated carefully. Links that use not only a different color but also some other means of differentiation, like a heavier font weight or an underline, are easier to use than links based on color alone. This is why Mobile Safari paints a dark grey roundrect over a link’s tap boundary when it’s pressed. It makes it explicit exactly which link you’ve tapped:

Apple’s goal of refining iOS down to its essential elements is a noble one. The video that they played again at the October Event yesterday is full of inspiring ideas. Unfortunately, much of iOS 7 suffers from an overzealous fixation on the reduction of visual flourish, ignoring the deeper functional roles that the previous visual effects performed. Buttons don’t have to be made from green felt or stitched leather, but they still need to look like buttons.

So I’m using normal mapping on pixel art. I’m surely not the first to think it up, but I don’t know of another game thats doing this (if so please let me know :D)

Here’s what it looks like without normal mapping:

And with:

Ignore for a moment the bricks making up the level, and those blob shadows under the characters. Almost all the shading on the sprites is done by the lights via the normal map. Why is this cool? because it means I can have moving lights that change the shading on the sprites:

Check out that skeleton in the pirate hat! blue lit on one side, red on the other. looks pretty rad. Here’s without the normal mapping:

yep.

So, how am I doing this normal mapping magic?

1 Have some awesome pixel art. I am using this awesome art from svh440! 

Then, I deshade, and animate it.

Next I enable most of the overlapping layers and build a combined heightmap, darker further back, lighter closer:

I could animate the heightmap, but so far that hasn’t been necessary.

This then gets a gradient over top to add more depth.

Woosh, into unity!

Heightmap gets made into a normal map:

Normal Map goes onto a Transparent/Cutout/Bumped Diffuse:

here you can see I have a sprite sheet that I scroll through for animation, but the normal map stays the same. If there is nothing to render for a particular pixel, it just ignores the normal map.

and BAM! Dynamically lit Skeleton:

Been a while since any .gifs, eh?