Here are some lessons in creating magical designs from Peter Smart from Fantasy Interactive.



These are drawn from his [Awwwards video, Creating Magic](https://www.youtube.com/watch?v=tRA6F7QykyY).

## Minimum Love-able Product

We all know what an MVP is. It's the worst thing that provides still provides value that we can release to our users. If we have more respect for our users and ourselves as designers, we will give them potentially much more.

If we ship an MVP, it's extremely difficult to iterate from something that's embarrassing to something that's magical. Once we set our hand to the first design and ship it, we have created inertia that is hard to escape from.

<div class="video-container">
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/tRA6F7QykyY?start=1772" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

## Convention is Permission for Better

We love design because we see the opportunity to create something that's better than the status quo. Don't be stuck in today's patterns for interaction or UI. Perhaps don't even feel constrained by your design system. Use it until it breaks, then make it better. Don't be replaceable by an AI designer that can compose widgets.

<div class="video-container">
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/tRA6F7QykyY?start=1796" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

## Draw from the Real World

Don't rely on the iOS interaction guidelines or guidelines for the other platforms that you're on. User interaction has existed far before that. Make interactions feel natural and human.

<div class="video-container">
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/tRA6F7QykyY?start=1831" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

## Think in Flows Not Screens

It's easy to approach work or divide work into features then stack them together into loose experiences. Instead, think more wholistically. Consider the desired outcome and the full experience, include transitionary states.

<div class="video-container">
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/tRA6F7QykyY?start=1831" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

## Less But Better

Get down to the essentials. Make the user of your product feel like they are interacting with the very essence of what a thing or activity is. It'll be empowering and feel right.

<div class="video-container">
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/tRA6F7QykyY?start=1910" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

## Fill it With Life

If you're full of joy and excitement when designing a thing, your user will be full of joy and excitement when they use it. Pay attention to those emotions to know if you're on the right track.

<div class="video-container">
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/tRA6F7QykyY?start=1910" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

Lessons in magical design from Peter Smart

Magical Design Lessons

You build a product.  Someone else builds a shared lib.  You want to use the shared lib in your app for its apparent utility.  There come _new_ features that the product team wants to adjust and add to your product.  The shared lib provides utility that is _related_ to these new features but does not provide these new features per se.



## Wishing the Shared Lib Did More
You think to yourself, "I wish this shared lib did this for me too."  

You might even go further to start adjusting your expectations and timeline around the shared lib. "I might just _wait_ until the shared lib does this for me.  It's already doing stuff in this area.  It should do it the related stuff too."  

After all, you have a lot of other stuff you'd rather do.

## The Feature I Need
If you wait, you may get lucky and get what you want.  Or, by the nature of the lib being shared, other constituents of the shared lib may have their own sway on it, pushing it in a direction that doesn't match the feature you need.   Or, the designer of the shared lib might not _want_ to add in the new features that are expedient for your product, thinking them ill-fitting of the shared lib.

## Independence to Move
You're already waiting, and you say, "Let's give the shared lib _more_ to do."  This seems like an equation for waiting more and shipping less.  You're putting your product in the hands of someone else.  That someone else may mean well, and you may trust him to eventually deliver on what you want in your product.  But you are reducing your independence by simply relying on the shared lib and its author.  

You're already waiting.  There's probably a reason for that.  What makes you think that if you continue _or increase_ reliance on this lib that you'll be waiting _less_ in the future?  In practice, many shared libs have simply less manpower than full product teams.  

Is it possible for you to affect the development timeline by your own effort and contribution to the shared lib?  If you're willing and have time to contribute to the shared lib, why not use that time and effort to further the needs of your specific product?  If you're not willing, then you really shouldn't be picky about what you get and when you get it, right?

## Owning Your Product
In the end you own and ship a product.  End users don't care if you use this shared lib.  You can get the job done many ways.  A shared lib that solves some of your problems isn't on the hook to solve all your future problems.  It's _your_ project.  Owning it is a mindset:  "I'm going to ship this thing as well and as quickly as I can.  I'll do what I can to gather helpful resources, such shared libs, and ask for help in order to make this happen.  But in the end, I'll make it work one way or another."

You're building a project that depends on a shared lib.  How will you evolve?

Depending on a Shared Lib

Sometimes a `table` element is the most semantic element one can use in markup.  It is true.  If you're displaying tabular data, a `table` is a likely option.  If you're on a responsive site, however, you'll cringe at this option.  It turns out that tables aren't very responsive web design-friendly.  One way to create a more responsive table is with scrolling.



## Responsive Table Options

I love the article by Chris Coyier that describes [responsive tables](http://css-tricks.com/responsive-data-tables/).  Some of his ideas and those of the commenters on his post a great at thinking outside the box on what the options include for responsive tables:

1. Orient the table vertically when there's not enough room for all the columns.
2. Replace tabular data with a graphic, such as a pie graph, that communicates the same gist.
3. Replace the table with a link that opens a scrollable view large enough for the regular-sized table.

My favorite option is the first.  But, in my case, it didn't seem to work extremely well because I have two headers.  The example had column headers only.  I have row headers as well.  After a bit more looking, I ran across this [Zurb scrolling table css and js example](http://www.zurb.com/playground/playground/responsive-tables/).  The best solution, it seemed for now, was scrolling.  (My example code is based on the markup and styles of the Zurb code with a few things taken out and a few things added.)

## Table Horizontal Scrolling

On the web, vertical scrolling is a part of the full meal deal.  So, the only thing to solve is the horizontal scrolling.  Normally, we don't want content flowing off the right side of the screen when browsing.  So, we when there's scrolling required, we're going to do it within the table only and for the columns we want.

#### Divide table in two

We want some columns to scroll and others to remain pinned whilst scrolling.  We'll duplicate the table in the markup and wrap each, a la:

```html
<div class="table-wrapper">
  <div class="pinned">
    
  </div>
  <div class="scrollable">
    
  </div>
</div>
```

#### Line up the rows

Now we have two tables.  The flexibility we've given ourself is that we can make some columns stick and others scroll easily.  Our new challenge is keeping the row height lined up so the two tables look like one.

Put the two tables next to each other with a float left and a float right.  Make the widths percentage-based as with any [rwd](http://en.wikipedia.org/wiki/Responsive_web_design).

Now we have a few options to make our rows line up:

1. Explicitly set all table cells to the same height
2. Use JavaScript to make each cell in a row be the same height as the tallest cell in that row
3. Put similar content in each cell on a row (eg, just text with the same attributes that will not wrap for longer text)

Turns out that I will choose option 1 for the table cells (`td`) and option 3 for the table headers (`th`).

This is my least favorite feature of this solution.  Anyone have a better idea on lining up the rows?

#### Set column width

I want some of my columns to have a set width.  Well, as *set* as anything is in rwd.  An html `table` will usually expand and contract columns across the table to give optimum spacing based on the content.

I want to make my pinned table columns allow extra-long content, but I don't want their widths to change at all.  A bit of StackOverflow love yielded this answer on why `overflow: hidden` doesn't work when [constraining table cell width](http://stackoverflow.com/a/7570613/118561).

In short, the solution is to wrap the content inside of the `td` with two `divs`:

```html
<div class="outer">
  <div class="inner">
    Row 4 longer than lotr
  </div>
</div>
```

And sprinkle with a bit of stylesheet:

```css
td .outer {
  position: relative;
  height: 30px;
}
td .inner {
  overflow: hidden;
  white-space: nowrap;
  position: absolute;
  width: 100%;
}
```

This style will let the column width remain and the content overflow.  It will also keep the cell text on one line, and it will be hidden as it flows off the right-hand side of the cell.  To wrap and hide as it flows off the bottom of the cell, remove the `white-space: nowrap` attribute.

## Responsive Table with Scrolling

For the final result, check out the [CodePen for the responsive table](http://codepen.io/jaketrent/pen/CcboI).

What are your suggestions for making this better?  How have you solved the responsive table challenge?

Responsive Table with Scrolling

The Agile method of software creation contains many principles of development that will help create good software.  Some of my most successful projects have had as a key feature an agile designer.  As Jobs said, design *is* how it works, and that means that to really deliver well in an agile environment, design *and* development have to be on the agile train together.



## K-man Keeps it Alive

I work with a fantastic designer, the one and only [Kendall Chadwick](http://www.composition3.com/).  He has many great qualities of an agile designer:

1. **He's available** - He lives with the cross-functional team.  He is there to participate in discussions.  It's not hard to get a hold of him, so answers to questions flow more freely.
2. **He listens** - He asks a lot of questions.  He's not stuffy about his design sense.  He realizes that many needs are represented in a project and product.  He attends discussion meetings not necessarily focused on design but on the details of the product or process.
3. **He's fully engaged** - He knows his task doesn't end when he clicks save in Photoshop.  He owns his designs and ideas all the way through the project, helping evolve them as we go. One of the most important things a software team member can do is remain fully engaged right up until the product ships.

## Agile Experience Design

I just finished a book called "[Agile Experience Design](http://www.amazon.com/Agile-Experience-Design-Designers-Continuous/dp/0321804813)" by Lindsay Ratcliffe and Marc McNeill.  I've read a fair bit on agile methods and currently live in a quasi-agile (hehe, let's actually call it mini-waterfalls) shop.  This book was intriguing as its authors are speaking to designers as they try to integrate better in an agile environment.

Of note was their Agile Design Manifesto:

Agile experience design is
Inclusive rather than elitist
Emergent with direction rather than up front
Integrated and collborative rather than handed over the fence
Considerate of customer, business, and technology needs rather than biased toward a single factor.

As a passing review:  The book won't provide too much that is new to someone familiar with agile.  It speaks in terms that I suppose are probably more well related to by designers.  It's a somewhat lengthy and dense book.  At times, it was hard to maintain reading momentum.  The book is beautiful -- perhaps it had some real designers laying it out?

## The Power of Design

It's amazing how much depends on solid design.  The design will define the users' experience with the software.  It will never not matter.  To a great design in a software product is a difficult thing.  Good people in the design discipline who are fully engaged in adapting to the changing landscape of software creation are invaluable.  Agile designers rock.  Find one and figure out how to get him on your project.

What have your best designers done to make great software on your teams?

Agile Designers

Have you ever showed up in the App Store looking for an app in a particular category and been overwhelmed at the number of choices present?  This is certainly the case for the drawing and art app category.  But, there is at least one art app that stands out clearly from the others: ["Paper" by FiftyThree](http://www.fiftythree.com/paper).



## Best Brush

The best feature of Paper is the one you get for free: the fountain pen.  It is easily the best brush I've used on any art app.  I've tried Sketchbook and Sketchbook Ink.  They are no where close.  It has the most beautiful tapered edges.  It responds best to speed and direction.  It comes the closest to a real fountain pen.

## Gestures

The rewind/undo feature is invaluable when drawing.  It is immediately available by using two fingers.  You can activate it anywhere on screen.  This makes for very fast iterations on a drawing.  It's both intuitive and fun.

## Flair

The app has a great style.  It's minimalistic and focused.  The notebook collection is fun.  The page flip is fun.  The UI is simple and powerful.  The focus remains on the drawing, where it should be.

## Sharing

Sharing is straightforward and fast.  Exporting your drawings into your photo library is easy.  It's just as easy to share on the web.  Tweet with "#MadeWithPaper" and you'll show up on their [blog](http://madewithpaper.fiftythree.com/).

## Pricing

I get the fountain pen brush for free, and I'm happy.  You pay $2 to get each of their 4 other brushes.  The next coolest is definitely the water color brush.  It totally makes sense to pay for these top-notch brushes.  Each brush takes considerable time and effort to develop.  Other apps -- I'm looking at your Sketchbook -- might include a pile of brushes at a lower price, but they are simply not as good.

## Wish List

There are a few things that I think the app is lacking:

1. The color palette is too simple.  I would love more options.  Apparently this is in the works.  There are many interesting [suggestions for expanding the palette](http://support.fiftythree.com/fiftythree/topics/colour_palette) made on their forum.  **Update:** The latest update has a [sweet color mixing tool](http://www.fastcompany.com/3002676/magical-tech-behind-paper-ipads-color-mixing-perfection).
2. A zoom feature would be nice.  The difficult thing would be mapping it to an intuitive gesture, especially differentiating it from the super-awesome rewind gesture.  The resolution is high (2048x1536), but it sometimes doesn't feel very high given that detail work is hard without a zoom.
3. Being able to change background/paper options would be awesome.  At this point, all you start with is a plain, off-white background with no texture.  The app is called "Paper", afterall.  Wouldn't it be nice to have some more options here?

The product features are well-thought and the FiftyThree team obviously has a design philosophy.  So, my pining for new features is patient.  I love what they have thus far.

## Magical

Using Paper really has been one of the magical moments of using the iPad.  It gives a slick experience that gets me drawing fast.  There are masterful, well-honed tools that make my art look good.  The use of gestures makes great use of the direct input ability of the touch device.  I've enjoyed many hours using Paper, and I look forward to more products from FiftyThree.

What is your favorite feature of Paper?  Or of another art/drawing app?

Paper by FiftyThree

With the advent of mobile devices, tablets, and screens attached to your toaster, we as web developers -- er, ninjas -- can no longer be ok with creating markup and styles that only appear properly in a traditional desktop environment.  Well, I guess we could, but we'd soon be defeated by much more gnarly ninjas.  Based on work and ideas of the Unstoppable Robot Ninja himself, your css dexterity is sure to reach levels of cosmic explosion by reviewing just a few principles of responsive design.



Ebb and Flow
------------

Programmers are lazy.  Designers are lazy.  I guess most people are, including those that are trying access our web content.  Historically, constraints, technical and cultural, made it easier for us to stay lazy as programmers and designers.  But now that you can view the web on screens many sizes and abilities, we can't live behind our naive constraints any more.  We must adapt or die -- that is, the exploding mobile web viewership will be lost to us and to our precious adwords.  Literally, if we don't adapt our designs, markup, and styles, it will break when viewed in a way that we didn't anticipate.

The Unstoppable Robot Ninja
---------------------------

In May 2010, Ethan Marcotte introduced his [article on Responsive Design](http://www.alistapart.com/articles/responsive-web-design/) at A List Apart.  I remember seeing the article pop up but obviously didn't realize the bodaciousness of the idea, because my ADD-prone website eyes couldn't finish the article.  (A List Apart articles are generally more well thought-out than the average blog muttering -- and longer!)  I first had my real exposure to the core ideas of responsive design at a webinar in Jan 2011.  Since then, I've dipped my toes in it a few times, and I like it.  The water's fine!  Come on in.  I really think it's a way to get some quick satisfaction that you're just a little closer to doing something -- anything -- for your mobile web users.

It's quick because the ideas are simple.  As Beep says, there are 3 main elements of responsive design:

* Fluid grid
* Flexible images
* Media queries

Responsive design seems to make people extremely... happy or mad.  Hehe.  I'm in the happy camp.  The mad camp seem to be those that believe that responsive design doesn't solve any real problems for mobile users.  I say, quit whining.  Take what good you can get from the ideas of responsive design and add something better to it.

I personally think it's almost easiest to just create a static width, unresponsive site first and then convert it to use more responsive styles.  Why?  Because a design is usually static (PSD).  And you can create the dimensions and ratios just right before trying to make them react to their environment.  

Fluid Grid
----------

So far, I've found myself ripping out blueprint, my previous static width grid system of choice and just doing my own thing.  Usually, the steps I follow are something close to this:

1. Build with static widths
2. Give max-width to outermost container and a percentage width
3. Search for widths or px values in stylesheet (Include things like left-right margin/padding, absolute positioning)
4. Comment each with:  current_width / container_width
5. Divide, multiply by 100, use % instead of px (Take full precision.  Ugly, but more precise)
6. Clean up -- figure out what shouldn't be variable width, instead fixed or mins, maxes

Note that I am usually changing only the widths because we're expecting that we didn't set heights, so the ratios will adjust automatically, and because vertical scrolling is acceptable and normal.

Fluid Images
------------

Really, most of the designs that I've converted to be responsive don't have images that go beyond their container's minimum width.  So, I haven't made my images of fluid width.  But, the idea with images is the same as the grid.  Set the width to be a percentage and probably some max-width as well.

Media Queries
-------------

These babies have been with us for a while (why, then, "babies"?), but it hasn't been long since we've started using them for responsive designs.  You've seen many a link to a stylesheet that specifies media="screen".  Well, now we'll add some compound logic and specify something about the screen or device dimensions.

Steps I usually follow for media query creation:

1. Choose your thresholds - I prefer simple lrg, med, sm versions
2. Use max-width on media query  (Put smallest at the bottom, so it will inherit all the attributes of the lrg and med stylesheets -- this cuts down on specific number of attributes in smaller dimension's stylesheets.)
3. Add viewport initial scale meta tag
4. Adjust elements that need to be different in smaller versions

My favorite combonation is usually 3 threshold sizes, approximately corresponding with a smartphone, tablet, and desktop-size screen.  I also tend to favor screen size queries instead of device mins and maxes.  It just seems more simple to me, and I don't have to know too much about devices. (And I don't -- they're too expensive. :)  Something like this (used for rockycode):

```html
	<link rel="stylesheet" href="media/styles/style-lrg.css" media="screen" />
	<link rel="stylesheet" href="media/styles/style-med.css" media="screen and (max-width:1023px)" />
	<link rel="stylesheet" href="media/styles/style-sm.css" media="screen and (max-width: 639px)" />
```

The max-widths are quite arbitrary and are really up to you.  I don't know if anyone's nailed down the "best" thresholds to make your media query jumps.  I tend to think it really depends on the vision for the site use and your main content.  How is that going to be best viewed?  And that potentially changes quite a bit between sites.

Now add this gem to make sure that you get no zoom out action happening when you load up your site on a small mobile screen that has a browser too smart for its britches:

```html
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
```

Voila!  That's really it.  At least it's as awesome as I'm making any of my sites right now.  I'm sure I have much kung fu to learn.  Again, I'm happy because it's something, and it gets me excited to learn more because it's easy and with a cool effect.  If you want to learn more, there are resources a plenty -- so many that someone needs to make a resource to compile a list of other resources.  And Beep's new book is out in a month.  Oh, then what awesome shalt be spewn forth upon the responsive web!

Other Musings
-------------

* Images are easier to resize if they're `<img />` instead of background-images
* Limitation - using media queries only, content like a sidebar is only going to flowable on top of on bottom of the main content
* Flow can get messed up quickly.  Things that were floated side by side might now be one on top of the other.  Have to look at adjusting top/bottom margin, etc (eg, the article tags on rockycode)
* Inline styles are not your friends for media queries.  Can't override.  Unless you use !important, then it feels messy.
* Responsive design makes you question where you put things in the markup.  If things are related to one another, they probably belong beside one another in the markup.  (eg, the clear filter link on rockycode that ended up at the bottom of the page)
* Just because your design is fluid doesn't mean it'll show up well in mobile browsers as your small-windowed desktop browser.  Mobile browsers have their own quirks too.  Test.

Burning Horizons
----------------

* Images - background-image flexibility
* Fonts - not quite as directly adjustable by screen dimension
* Forms, apps - everyone's belly-aching about this; what's the deal?
* Small js frameworks- network latent device friendly replacements for monolith frameworks
* Flexible grid systems - might not have to roll my own for much longer
* User generated content -- accomodating for what's not on the site at launch.
* Modernizr - device feature availability mixed with media query awesome

Final Gem
------------

"At some point, everything breaks.  (But it's okay!  Really!)" - Ethan Marcotte, respected founding father of the responsive web

A File for a Workshop
---------------------

[responsive.zip](https://bitbucket.org/jtsnake/rockycode/downloads/responsive.zip) - static html version of an example article from this site roughly corresponding to a revision that was not responsive ([r124](https://bitbucket.org/jtsnake/rockycode/changeset/6d4d197239da)), ready for some coding to advance to the responsive revision ([r136](https://bitbucket.org/jtsnake/rockycode/changeset/fc4d96ec91f2)).

With the advent of mobile devices, tablets, and screens attached to your toaster, we as web developers -- er, ninjas -- can no longer be ok with creating ma