Category

• # Spring Animations

I was working on some prototypes which required me to animate properties which were not supported by UIKit animators. So I was left with no choice but to build my own animator.

No worthy animator exists without springs. And I knew nothing about springs beyond "they are bouncy!". I had a lot to learn.

I remember looking at those properties of a spring (mass, stiffness, damping, velocity) and had very little idea of what they meant. Creating a spring was more of a guessing game inputting numbers randomly until I got something that worked.

Well let me tell you, it took a LOT of googling to understand these damn, I mean awesome, things! Most articles were super advanced and assumed a greater understanding of math than I currently have. So I wanted to try to write my own post, targeted at designers and developers who, like me, might not have prior understanding of these principles.

I’m going to try to get as basic as possible, which at times may be too basic for some of you.

I’m also going to explain why stiffness and mass don’t need to be manually set, but it helps to understand springs in order to understand why that is.

# Hooke’s Law / Harmonic Oscillators

First of all, let’s forget about the spring in the real world. The springs we know have a size, a thickness and often have something attached at the end of them.

But in mathematical terms I spring is what’s called a Harmonic Oscillator. Basically an infinite wavy curve like this.

To “draw” this curve with math you obviously need to plot the position over time.

So let’s break that down.

If we're drawing a wavy line, it means there a change in velocity going on - acceleration and deceleration. And if there’s acceleration then there’s gotta be a force making it go faster and slower.

A resting spring has no force, so you need to “activate” it by pulling it. How far you pull is called our displacement.

Now that it’s pulled, there’s a force pulling it back to its original position. There’s a special formula to get the force of a spring based on Hooke’s Law.

F = -kx

k is a stiffness coefficient

x is the displacement value (how far the object moved from previous value)

Force = Negative Stiffness Value * Displacement value

Notice that mass is not a part of this force. All we need to define a spring’s force is how stiff it is.

We have the force, so we can calculate the acceleration.

The formula for acceleration is:

a = F ÷ m

Acceleration = Force ÷ Mass

The mass will be a constant, say 1, since we’re assuming our object is not changing weights.

That means our acceleration is:

a = (-kx) ÷ m

Acceleration = (Negative Stiffness × Displacement) ÷ Mass

Now we know the acceleration, we can calculate the velocity of our object at any given time.

To accelerate velocity you need to add the acceleration rate to the previous velocity.

v1 = v0 + a × t

New Velocity = Previous Velocity + (Acceleration × Time Interval)

The time interval when it comes to computers is normally set in frames per second (hertz).

60 frames per second = 1÷60 = 0.016666 seconds

Finally, you can calculate the new position.

p1 = p0 + v × t

New Position = Old Position + New Velocity × Time Interval

Do you see how that never-ending wave is formed? The displacement (x) affects our force since F = -kx. So that means that the force will change based on how far it’s displaced, and if the force changes the acceleration changes too, and if the acceleration changes the velocity changes and the displacement changes, which affects the force…  ðŸ¤¯

All it means is that this will go on forever making the oscillator curve with nothing to stop it. Which is obviously not what we want in an animation.

And that’s where damping comes in.

## Damping

In nature, no spring is perfect like that. There are forces at play like friction and heat. So the springs we are familiar with always stop at some point. That stopping force is called damping.

The damping force formula is:

F = -dv

Force = Negative Damping Coefficient × Velocity

## Damping Ratio

The necessary force to damp a spring varies on its stiffness and its mass. So, a much easier way to deal with it is to calculate a damping ratio. Which you get get through this formula:

ζ = 2 × m × (√k÷m) × d

Damping Ratio = 2 × Mass × (√Stiffness÷Mass) × Damping Coefficient

Damping Ratios also get some fancy names depending on their value:

• Critically damped   Damping Ratio = 1 (The most common in Apple UI)
• Over Damped         Damping Ratio > 1  (Not a good look, not often used in UI animation)
• Under Damped       Damping Ratio < 1  (The smaller the number the bouncier it gets and the more likes you get on Dribbble.)

Back to our formula, now you have the dampening force, you just add it to your spring force, and your spring will stop.

With the new damped force, our acceleration formula looks like this.

a = (-kx) + (-dv) ÷ m

And so you get a spring that looks more like this:

## Time

Notice that time is not a variable that we’re setting, and normally when you’re animating something you want to tell it how long it’s going to animate for.

Well, I’m sorry to tell you that springs don’t really care about time. They’ll just take however long it takes them to come to a stop. And that’s a problem for me because I find it more intuitive and feel more in control when I can specify how long my animations will last.

Luckily, math is on our side. Your mass, stiffness, and damping all can influence the time it’ll take for the spring to rest.

The formula for relaxation time took me a long long time to find. Wikipedia and most of the internet has a formula that does not at all work for me in practice.

It's almost impossible to get an exact relaxation time because the spring can continue moving minutely for a very long time. What you're looking for then is when will the spring reach a fraction of the initial amplitude, in other words, when does it look like it stopped moving.

Let's say the fraction we want is 1/1500. Here's the formula to find how long it will take for the spring to reach that amplitude:

t = (2 × m × ln(1500)) ÷ d

Time = 2 × Mass × NaturalLog(1500) × Damping Coefficient

That means you can technically control the mass / stiffness / damping to match the approximate time you want the spring to come to a rest.

### Setting a Spring Using Duration and Damping Ratio

Like I said in the beginning, you don't really need to worry about mass and stiffness on an animation. It's unintuitive and mostly what you care about is how long the animation will last and how springy the animation will be.

How can you calculate the mass, stiffness and damping coefficient given a duration and damping ratio?

To make things simple, you can set one of the values as a constant. I’ll pick mass as that's the simplest, and set it to 1 (the number here does not at all change the final spring since damping and stiffness are recalculated to overcome the mass).

That leaves us with two values to calculate, our stiffness and damping coefficient.

I want our damping ratio to be 0.9 (remember this is the ratio as explained above, not the coefficient), and our animation to last 1 second.

k = (m  × ln(1500)²) / t²  × ζ²

stiffness = (Mass × NaturalLog(1500)²) × Time²  × Damping Ratio²

c = 2 × ζ × (√k÷m) × m

Damping Coefficient = 2 × Damping Ratio × (√stiffness ÷ mass) × m

Thus:

dampingCoefficient = 11.84

stiffness = 43.32

So, if you set your spring with a damping coefficient of 11.84, mass of 1, stiffness 43.32, it will rest in approximately 1 second and have a damping ratio of 0.9.

### Swift

I’ve been doing all this in swift and made a little git gist with the formulas.

Note that this is not the actual code or formula used by Apple for UIViewPropertyAnimator(duration: TimeInterval, dampingRatio: CGFloat) method. They do some complicated secret sauce, keeping the mass at a constant of 1 and changing the stiffness instead.

So if you apply the formulas above and make an animator and play alongside an UIViewPropertyAnimation you’ll see slightly different results.

• # iPhone 6 sizes and Grid

I don't intend to go in-depth about the funkiness of these new resolutions, so I recommend reading these 3 links to get the full picture.

In short, the iPhone 6 Plus is this kind of faux 3x. So your Photoshop canvas should be set to 1242âœ•2208 but the device will downsize it to 1080âœ•1920, which in a 2x world would look like the equivalent of 828âœ•1472.

That's because of the higher PPI (pixels per inch):

• A 1x, 10px tal element renders as 1.5mm on 163 PPI
• A 2x, 20px tall element renders as 1.5mm on 326 PPI
• A 3x, 30px tall element also renders as 1.5mm on 401 PPI

Here's a visual representation that hopefully explains what's going on.

2x Equivalency

The equivalent size helps me visualize the extra room that you get on the screen, because not only it's 3x pixel density but it's also higher resolution (more screen real estate) and that's too much for my wee brain to work out while designing. So, to help us understand, if you're used to designing for an iPhone 5s at 2x, your canvas would be the equivalent of 828 âœ• 1472 for the 6 Plus.

Design Strategy

Mostly what that means is that your mobile app designs now need to be responsive not only vertically but horizontally too.

I'm thinking I'll just design for the 4.5" screen and keep in mind what would rescale and realign when resizing up and then show in red-lines what flexes and what's fixed. And in certain circumstances I'll design specific screens for the 6 Plus to make use of the extra room. But, for the 6 Plus I'll design it in the 2x equivalency because I'm used to it, and then use PaintCode for glyphs and for images (like photos / avatars) they'll need to be generated in 1x, 2x and 3x.

Grid

The new resolutions are not all multiples of 8 (odd), but the grid can be an approximation of that. So here are some PSD templates with the grids.

Please refer to my post on Photoshop Secrets for usage.

• # iPhone Grid

Before you just go download it, let me explain the thinking behind the grid.

The iPhone resolutions so far are:

640 âœ• 960   &   640 âœ• 1136

If you want to sub-divide those into the largest possible squares you need to find the highest common divisor. On the iPhone 4 that is 32px, on the iPhone 5 it's 16px.

The iOS grid uses 16px divisions, sometimes subdivided into 2. Gutters don't apply to UI design as UI by nature is too dynamic to add such constraints. You'd find yourself having to break the grid all the time to properly lay your elements in a logical manner.

8, 16 or 32 pixels apart?

As a rule of thumb, based on the Principles of Grouping (law of proximity), elements that are related should be no more than 16px from each other and elements that are not related should be at least 32px from each other.

Apple sometimes uses an 8px grid with widgets that are divisible by 8px instead of 16px, and by having elements spaced out in 8px increments (8, 24, 40, 48, etc). I find this unnecessary for the most part and prefer to stick to multiples of 16.

If you must break the grid, or just want to be a rebel, do at least stick to spaces no smaller than 8px and to multiples of 8px. For the sake of this grid file I created a 16px grid as an 8px distance is the exception, not the norm.

Margins

There are 2 vertical margins on iOS, outer 16px (for title bar navigation such as back button, etc) and inner 32px (for content).

Horizontally the status bar is 32px and the margin follows 32px beyond that. At the bottom the nav bar icon labels are aligned 8px from the bottom, which is why I put a smaller margin.

How to use the file?

I recommend is that you place the PSD into your document as a Linked Smart Object (File > Place Linked). At have it as the top layer of your document. Set it to Locked, set blending mode to Multiply, and then toggle visibility on and off and change opacity as needed.

Another thing I recommend doing, which in a way makes this PSD kind of pointless, is to set your Photoshop grid to 32px with 2 subdivisions, this allows for easy snapping of objects to that grid.

Make sure you then set Grid visibility on by going to View > Show > Grid or pressing âŒ˜ ' to toggle (' is the key next to the return key on a US Mac keyboard).

Grid Toggles

I found it useful to toggle between 32px and 16 px grids as well as horizontal vs vertical grids. So when you place the file as a Linked Smart Object, in the Property Panel, with the grid layer selected, you will see these toggles:

Ok, so without further ado... here's the PSD.

And here it is applied to Apple Mail app

• # Icons vs Labels vs Both

The debate of icon /  text and icon + text label always fascinated me. Gmail started out with an all text interface and very few icons, recently it changed to the polar opposite and went on mostly icons with very few labels. But which is better? And why?

Novice users are not as familiar as we are with certain conventional icons, making an icon-only interface potentially harder for them to use. On the other hand, to the tech-savvy users, having text labels everywhere may be perceived as cluttered and unnecessary. So how do we make everyone happy?

After some googling on the subject I found a fascinatingly detailed study on the usability of icons only, text only and icons + text. You can read it here if you want to know every detail about it, but below are some of my highlights and what I learned from it.

## QUICK INTRO ON ICONS

Icons have been used on a limited basis since the early days of computer graphics. The popularization of iconic representation in the interface dates to the work of David Canfy eld Smith and his colleagues who developed the interface of the Xerox Star workstation (Smith et al. 1982; Johnson et al. 1989). Icons are used in the interface because they are presumed to facilitate the human-computer interaction.

It is easy to find enumerations of the supposed advantages of icons in popular literature. Some claims that have been made are the following:

• icons improve the productivity and reliability of work;
• icons are better than words for representing subtle visual and spatial concepts;
• icons save space;
• icons speed search;
• icons lead to immediate recognition;
• icons lead to better recall;
• icons reduce the necessity of reading;

All of these claims about icons implicitly compare icons to text in the interface. Many of the claims are psychological or perceptual in nature: that icons are easier to process than text.

## NOT ALL ICONS ARE CREATED EQUAL

Icons differ in the degree of abstraction. Several icon classifications exist in the literature. Representational, abstract, and semi-abstract.

 Representational (an eraser for "delete")Representational icons are simplified images of familiar objects or operations, for example, an image of an eraser to indicate a selective deletion operation. Their concreteness tend to be most effective since a small articulatory distance aids recognition. Eraser > Erase > Delete.However, icons embodying an isolated analogy are often difficult for computer users to interpret, even concrete analogies, e.g. a wheelbarrow loaded with bricks to represent a move operation. Abstract (a curved arrow for "reply")Abstract icons employ geometric shapes or graphic symbols instead of concrete images, for example, a curved arrow to represent “reply”. Semi-abstract (an arrow pointing to a folder for "move")Semi-abstract icons combine a representational pictorial element with an abstract symbol, for example, a folder with an arrow that indicates placing items in it.

## IMPORTANT CONSIDERATIONS

• Icon sets with more visual variety are easier to locate in a display
• Visually simple icons work better than complex icons in icon search
• Positional consistency in presentation of icons on the screen has a strong effect on usability and, once learned, helps compensate for initial differences in recognizability
• Icons must be immediately recognizable to the targeted user population and use graphic conventions familiar to that group.

## IMAGE SUPERIORITY EFFECT

When it comes to memory, researchers have known for more than 100 years that pictures and text follow very different rules. Put simply, the more visual the input becomes, the more likely it is to be recognized and recalled. The phenomenon is so pervasive, it has been given its own name: the pictorial superiority effect, or PSE.

All user interfaces make cognitive demands on users. Users must master special rules of system use, learn new concepts, and retain information in short-term memory. They must create and refine a mental model of how the system works and how they should use it. Successful user interface designs must respect the limitations of human cognitive processing.

Tests showed that visuals are processed 60,000 times faster than text, and people could remember more than 2,500 pictures with at least 90% accuracy several days post-exposure, even though subjects saw each picture for about 10 seconds.

The inefficiency of text has received particular attention. One of the reasons that text is less capable than pictures is that the brain sees words as lots of tiny pictures. And when we read, most of us try to visualize what the text is telling us. We essentially create icons inside our heads.

Using icons or symbols on a device serve as aids to memory, thereby reducing cognitive load since we can process icons and symbols much quicker than we can read text.

Graphics do what text alone cannot do. They quickly affect us both cognitively and emotionally:

1. Cognitively: Graphics expedite and increase our level of communication. They increase comprehension, recollection, and retention. Visual clues help us decode text and attract attention to information or direct attention increasing the likelihood that the audience will remember.
2. Emotionally: Graphics enhance or affect emotions and attitudes. They engage our imagination and heighten our creative thinking by stimulating other areas of our brain, which in turn leads to a more profound and accurate understanding of the presented material.

## USEFULNESS OF ICONS

There are several reasons why the use of icons might have advantages over text in terms of human-computer interaction. It's been shown that recognition of visual images is superior to either recognition of words or sentences, and that humans have an almost unlimited ability to recognize images that they have seen before.

There are distinct resources available for different activities, such as perception and cognition. If the primary task is a problem solving task which requires cognitive resources, then the use of icons, which draw on a perceptual resource pool, may make more resources available for the primary task. A text-based interface, on the other hand, might compete with the primary task for cognitive resources.

Two kinds of perceptions are important in the acceptance of a system: perceived usefulness and perceived ease of use.

• Perceived usefulness (PU)
Perceived usefulness is the user’s subjective perception of the extent to which the system or software will aid in job performance. If you want to edit a movie and you open FinalCut Pro with all its movie editing related options you may perceive it as “useful”
• Perceived ease of use (PEU)
Perceived ease of use is the extent to which the user expects a system or software to require low effort to learn and use. When you open FinalCut Pro for the first time and you see all its movie editing related options, you may perceive it as “hard to use”.

The relationship of attitudes to the behavioral intention to use a system is that, all other things being equal, people will form an intention to use a system about which they have positive attitudes.

Icons give a positive early impression and thus support the formation of positive perceptions of ease of use and usefulness.

## THE RESEARCH FINDINGS

Icons make systems appear more accessible to the new user may have the effect of increasing the perceived ease of use of a system and the user’s corresponding behavioral intention to learn and use it. With positive perceptions about a system, users are more willing to persevere in learning it in the face of any initial difficulties.

Icons with text labels were easier for participants to learn to recognize correctly but subsequently took more time for participants to choose from a display than unlabeled icons. However, it was also found that, once learned, there was little difference among icons in recognizability.

The combination of icons with text has the possibility of disambiguating the meaning of the menu choices available in the interface.

The results indicate a learning advantage for the label-only and icon + label interfaces compared to the icon-only interface for correctness, time and use of help.

On the other hand, the advantage in terms of correctness, although significant, was less exaggerated, suggesting that most participants could do most of the tasks regardless of the interface, simply by continuing to try different solutions until they were successful. The success of the label-only and icon + label groups suggests that in early learning text labels are more informative than icons.

The lack of difference between the label-only and icon + label groups in most comparisons suggests that the labels were the element that aided learning.

From these results, it appears that providing icons in combination with labels added little extra information of use in learning to manipulate the interface beyond what was conveyed by the labels.

A key question about these results is why the icon-only group performed so poorly. The point has been made in the past that icons, even representational icons, have to be learned. In early learning the meaning of the icons must be interpreted, and the meaning may not be obvious to the beginner from a pictorial representation alone.

Icon-only users have to first interpret the pictorial symbol then interpret its meaning in terms of system functionality. This dual burden is especially heavy in the case of learners who have low experience with both computers and the applications area. These learners have two disadvantages in interpreting icons. First, they do not known much about what the program they are learning is capable of doing. Without this knowledge, it is difficult for them to infer functionality from an icon alone. Second, they know little about the conventions of iconic representation. For example, more experienced learners know that a trash can-like object is often used to represent deletions, a file folder-like icon to represent a container for documents, a house icon to represent the home screen etc. Experienced learners can interpret these objects when they learn new interfaces, even though the objects are slightly different in form from those they have previously encountered. Thus, for learners more experienced with computers and the special c application, we would expect better performance with the icon-only interface than was seen in this experiment. While experienced learners will still have to learn unfamiliar icons, there will be fewer such icons and the learners will have a better basis for interpretation because of their past experience.

Although the icon-only group learned more slowly, made more errors, and used more help in early blocks of trials in session one, it should be noted that they closed the gap relatively quickly. So the difficulties of interpretation of unlabeled icons can be overcome fairly rapidly.

The icon + label interface was always considered easier to use than either of the other interfaces, including the label-only interface. This is a case in which perceptions do not match performance, since the label-only group inconsistently performed as well as the icon-label group. It appears that an interface designed with icons suggests ease of use to the learner and is rated easier to use partially independent of performance.

The icon+ label and the label-only groups had an easier time getting the interface to do what they wanted in session one and, as a result, probably gained a better understanding of system functionality initially than did the icon-only group. So their perceptions of usefulness were formed at that early point and remained fairly stable as they gained more incremental skill in session two.

## CONCLUSION

The results of this study lead to the conclusion that learners of application programs are aided in initial learning by the use of either icons with text labels or text labels alone.

Icons lacking labels performed very poorly in the early stages of learning, although learners of the icon-only interface caught up with the performance of the other two groups by the end of the first session.

Learners have less favorable perceptions of the usability and usefulness of text-only interfaces.

On the basis of our results we recommend the provision of text labels in initial use of iconic interfaces.

When words and icons are closely entwined, we augment intelligence by increasing ‘human bandwidth'—the capacity to take in, comprehend, and more efficiently synthesize large amounts of new information.

Learners who have little knowledge of the functionality of the application program and who have little knowledge of representational conventions often used in iconic interfaces are most in need of aid. These users have little basis for making inferences about the meaning of icons in the lack of text labels.

This suggests that the text labels play an important role briefly in the early stage of learning, but after that they lose their value. From this, it appears that labels may be suppressed after the users have worked with the program for a relatively short time.

## MY SUGGESTIONS

• Use icons whenever possible
• Initially show labels, with an easy to locate option to turn them off.
• On desktop software/web apps, show labels smoothly animating on hover
• On touch interfaces to show labels for a few seconds after launch and then fade them out. The labels could appear again on press and/or press+hold.
• Show labels for the first few uses of the app, and once the user has tapped all or most icons in the app, hide the labels automatically and have it as an easy option to turn them back on.

SOURCES

• # Skeuominimalism - The Best of Both Worlds

What the hell is skeuominimalism? It's skeuomorphism mixed with minimalism.

What the hell is skeuomorphism? It's when an application tries to mimic its real-life counterpart. It's an object (or interface) that retains ornamental design cues to a structure that was necessary in the original but is no longer necessary. Kind of like adding a smokestack on an electric train.

The Calendar app on OS X is replete with leather, seams and a torn page. All ornamental and unnecessary beyond the familiarity factor.

One of the consequences of skeuomorphism is that when merging real life visuals with digital interactions the models start to break. You end up with leather buttons, serif type on a lined notepad, false affordances like pages that you can't really turn, and even a cookie crumb that you can't clean up. So as it tries to create familiarity to users it can also create confusion and awkwardness.

Check out skeu.it for some of the gems of skeuomorphism.

However, at its core, skeuomorphism is more than just the gratuitous mimicry of the look of a leather calendar. Buttons, shadows, ridges and toggles are skeuomorphic functionalities. Swiping, pushing and pulling are also real life interactions and could perhaps be called skeuomorphic, since they are not absolutely necessary to the functionality of the interface. But this is where the lines blur, and I would argue that although not necessary, they make it easier for our 3D brains to understand how to interact with a 2D interface and thus serve an important purpose.

Tom Hobbs says in his post about skeuomorphism:

There is validity to a skeuomorphic approach. To create any good interface, it is essential for the designer to understand the cognitive models that a user brings to any new product.

Since we have evolved interacting with 3D physics and not 2D screens to our brains buttons "ask" to be pressed, handles "ask" to be pulled, switches "ask" to be toggled. We instinctively know that smooth surfaces are harder to push than ridged surfaces. If an object casts a shadow our brains automatically perceive it with volume or on different plane. These are all affordances that as designers we should take advantage of and mimic on our interfaces.

### Now let's look at the flip side of that coin. Minimalism.

Microsoft's new design language, Metro, is beautiful. Few disagree. It's minimalism turned all the way up, it's completely digital, so it looks nothing like real life counterparts. The unfortunate consequence is increased cognitive load and lack of affordances. In other words, the user needs to "think" before performing an action. Their brains struggle to figure out what can or cannot be tapped. They don't know what can be swiped, pushed or pulled because there are no real-world (skeuomorphic) hints for their brains to rely on (shadows, volume, texture, etc).

What Metro gains in visual beauty, it lacks in usability.

### So what if we took the best of both worlds?

What if we added those visual affordances abundant in skeuomorphism to minimalistic UIs so they are easier for users to quickly grasp your application? I like to call it "skeuominimalism".

Skeuominimalistic design is simplified up to the point where simplification does not affect usability. And its skeuomorphic affordances are maximised up to the point where it does not affect the simple beauty of minimalism.

Make it minimal, but do not make away with shadows, lighting, volume, depth, focus and textures when they are necessary for affordances.

The new iTunes is a great example of skeuominimalism. By using physical familiarity of shadows, gradients and highlights the buttons afford to be pressed. The soft noise and gradients gives it a bit of mood lighting. It looks beautiful!

Jasmine, a YouTube client for iOS, perhaps goes a bit too far on the minimalistic side (by sometimes losing affordance in favor of simplicity) but it still uses shadows (for depth/hierarchy) and soft gradients for mood lighting.

And then there's the series of Mountain Lion apps redesigned without the unnecesary parts of skeuomorphism, a worthy exploration of minimalistic yet easy to use interfaces.

In essence, skeuomorphism is not all bad - overusing its unnecessary ornamental visuals can at this point be considered cliché and a bad design choice in my opinion. But using physics and 3D affordances makes it easier for us humans to interact with apps and thus we as designers should take advantage of that!

I'm Edward Sanchez, User Experience and Visual Designer at Amazon for the Kindle.

@edwardsanchez

• # iOS Icon Template

This template lets you design iOS icons and automatically resizes, sharpens and adds highlights. Just edit 1 Smart Object and all icons will be handled for you.

Once you're finished, drag the PSD to Slicy and the PNGs will be automatically exported with the correct name, sizes and without the rounded corners (as they should be).

• # Photoshop Presets / Settings / Keyboard Macros

Installation Instructions
Plugins
1. In your Application Folder go to Adobe Photoshop CS5 / Plug-ins / Panels
2. Copy the folders Corner Radius and guideguide inside the Panels folder.
Presets
In the folder called Presets, select all the files and drag them to the Photoshop icon in your dock. You'll notice that nothing happens but that's ok. If you do it again you'll get duplicates.

Workspace
1. With Photoshop Closed go on Finder and Navigate to /Users/(yourname)/Library/Preferences/Adobe Photoshop CS5 Settings/WorkSpaces/
2. Then drag the file called "UI Workspace" to that folder.
3. Open Photoshop and click on Window > Workspace > UI Workspace and you should notice the panels change around.

This workspace is designed to work with a large monitor + a laptop screen, so things may look out of place. It's ok for you to drag things around to make it work for you but all of these panels are important so don't completely dismiss any of them.

Settings
On the bundle I'm sending there's a folder called Settings with screenshots of my Photoshop settings.
Just make sure that your Preferences match each of those for better performance and improved tools.

Keyboard Maestro + Photoshop Shortcuts
1. Drag the Keyboard Maestro app into your application folder
2. Open it and exit out of the welcome screen
3. Click File > Import Macro Library
4. Select the file Keyboard Maestro Macros.kmlibrary from my folders
5. You'll see a screen with the button INSERT, click that and it'll import these macros
6. You then need to enable access to assistive devices by opening System Preferences > Universal Access > Tick Enable access for assistive devices at the bottom - close out.
Back in the Keyboard Maestro Groups you should now see a folder called Photoshop, and inside it you'll see several Macros and they keyboard shortcuts that trigger them. Open Photoshop and try them out.
Panel Options
Many panels in Photoshop need to be configured to show the best options. You can access these by clicking  on the top right of each panel.
• Tool Presets Panel: Small List and Show All Tool Presets
• Actions Panel: Button Mode
• Styles Panel: Large list
• Info Panel: In Panel options, tick every box
• History Panel: In Panel Options the first 3 options should be ticked.
PS: Keyboard Maestro requires a license to run past 30 days. I highly recommend getting it!
PPS: Some of these shortcuts I set require a full Mac keyboard with Numpad.