Last week I was watching an interview with the incredibly talented Jessica Walsh. I’m always curious as to how the world’s most creative people operate because I don’t really consider myself a very “creative” designer in the art sense.

She said something very profound about one of the most important aspects of her highly lucrative creative career: play. At the start of any project or exercise, Jessica allows herself to just play. She has no predetermined set of rules or processes and she’s not caged in to any of the static limitations we tend to put on our creative work.

I’ve been sitting on this idea of “play” as a creative asset over the last week and decided to put it into…well, play.

The Importance of an Anti-Process Process

I was having a discussion with my friend Yaron yesterday about the plaque of process that the design and development community tends to force on itself. I asked him what his philosophy was when approaching a new design problem and he said he doesn’t favor process. He would rather daydream and allow his mind to discover all of the possibilities without committing to even the slightest of static wireframes. He would rather “play” to discover new opportunities, than to limit himself to the same frameworks, processes, strategies, and boilerplates used on multiple other projects.

Many times “play” becomes the anti-process process that we need to create something new, something outside of the normal framework. When we put something down in Photoshop first or we sketch the first wireframe for a site’s navigation, we’re subconsciously limiting ourselves to a static idea constrained by what we’ve already seen or done. This rarely leads to a new, more innovative solution that sets you apart as a unique designer.

Opening Your Mind’s Eye

Part of being a great designer is developing the ability to truly see with a design eye. Seeing doesn’t always limit itself to the physical act of looking at something. One of the powerful side effects of playing is that your mind is free to discover all angles of a design problem.

Most of the design challenges we face are designing solutions for people to use out in the world, yet we find ourselves trying to solve them from behind the discomfort of our desks. If you’re designing an iPhone app for a restaurant, take a trip to a restaurant with a friend and start to “play” with ridiculous ideas and watch the little nuances that will present themselves while observing how people actually use their phones in the restaurant.

What you discover when observing and playing with ridiculous notions will give you insights you never would have thought about by starting your project out in Xcode.

Google’s Secret Weapon of Play

One of Google’s secret weapons of designing a new product is to use video to tell the story of a design before it has even see the first prototype. Rather than creating a design first and expecting people to adapt to it, Google’s designers will take their idea down to the video team and let them play with the idea first. Allowing a creative third-party to produce the story of the idea, helps you to see a completely new approach without the limitations of an early static comp.

Play leads to breakthroughs and real-world imagination of use and application. By placing physical design further down the timeline, Google’s design team is able to see multiple design problems and solutions without having to spend hours “guessing” at solutions.

Go Play

Before starting your next design project, try to leave Photoshop and code out of the idea process. Grab a camera and make a video, take the time to imagine the craziest uses you could fathom, or just ask non-designers to make your site out of construction paper. Design a website upside down or create a new interface that is completely off-grid. Do something that is completely ridiculous and get out of your comfort zone.

Be comfortable with playing and use it as a creative asset. You’d be very surprised at the new opportunities that come from it.

The post The Power of Play appeared first on Treehouse Blog.

Everyone loves motion. Adding the fourth dimension (time) to a site design is the main way screen-based design stands out from print design. CSS Transitions are a simple method for animating properties of an element enabling you to enrich certain events in your web design, without the need of Flash or JavaScript.

The W3C aptly describes transitions on their website as “CSS Transitions allows property changes in CSS values to occur smoothly over a specified duration”. In other words, CSS transitions allow us to modify a property incrementally, creating a sensation of motion and imbuing designs with subtlety and emotion that isn’t possible with a quick change.

Browser support

All modern browsers (yes even IE!) now support CSS transitions. However, importantly, if transitions aren’t supported in the browser being used, the transition is ignored and the property changes will be applied instantly. This graceful degradation is a cornerstone of best practice.

In order to extend the range of browser support we can use vendor prefixes, this extends the feature to include Firefox 4–15, Opera 10.5–12 and most versions of Chrome and Safari. The code, including the vendor prefix alternatives looks like this:

div {
  -o-transition: all 1s ease;
  -moz-transition: all 1s ease;
  -webkit-transition: all 1s ease;
  transition: all 1s ease;
}

The non-prefixed property is added at the bottom of the stack to ensure final implemantation will trump all the others, as the property moves from draft to finished status.

Transition parameters

There are four parameters for CSS transitions:

• transition-property: the property to be tweened, or the keyword ‘all’ to apply to all properties;
• transition-duration: the duration of the transition;
• transition-timing-function: the easing to be applied, this creates more natural looking movement
• transtion-delay: specifies a delay to the start of the transition.

In addition, you can also use the shorthand property (as in the example above) where the parameters are specified as property, duration, timing function, delay.

Properties that can be transitioned

You can only transition properties that can be translated into a mathematical value. So for example, you can transition font-size; you cannot transition font-face.

The full list of properties that can currently be transitioned is as follows: 

background-position, border-bottom-color, border-bottom-width, border-left-color, border-left-width, border-right-color, border-right-width, border-spacing, border-top-color, border-top-width, bottom, clip, color, font-size, font-weight, height, left, letter-spacing, margin-bottom, margin-left, margin-right, margin-top, max-height, max-width, min-height, min-width, opacity, outline-color, outline-width, padding-bottom, padding-left, padding-right, padding-top, right, text-indent, text-shadow, top, vertical-align, width, word-spacing, z-index.

Using transitions

Transition declarations are attached to the normal state of the element. Therefore only declared once for several states such as :focus, :active and pseudo classes.

Using the following code we can set up a basic menu and a paragraph of text. It is styled so that the menu items change their color and background color when rolled over, and so that the inline link changes its underline color from white to green when hovered over:

<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="utf-8" />
 <title>CSS transition demo</title>
 
 <style type='text/css'>
 
 /*
 
 STATIC PROPERTIES
 
 */
 body {background:#fff; }
 ul { padding:0; margin:20px; }
 li { display:inline; padding:5px 0; }
 .nav a { padding:5px; }
 p { padding:0; margin:21px; }
 a { text-decoration:none; }
 
 
 /*
 
 PROPERTIES TO TWEEN
 
 */
 
 .nav a
 {
 color:#bee0bf;
 background:#1a9e5c;
 }
 
 .nav a:hover
 {
 color:#fff;
 background:#38b476;
 }
 
 p a
 {
 color:#3fa32d;
 border-bottom:1px solid #fff;
 }
 
 p a:hover
 {
 color:#bee0bf;
 border-bottom:1px solid #3fa32d;
 }
 
 
 </style>
</head>
<body>

<ul class='nav'>
 <li><a href='#'>Business</a></li>
 <li><a href='#'>Code</a></li>
 <li><a href='#'>Design</a></li>
 <li><a href='#'>Inspiration</a></li>
 <li><a href='#'>Miscellaneous</a></li>
 <li><a href='#'>Mobile</a></li>
 <li><a href='#'>News</a></li>
 <li><a href='#'>Resources</a></li>
 <li><a href='#'>Usability</a></li>
</ul>

<p>Integer posuere erat a ante <a href='#'>inline link</a> venenatis dapibus posuere velit aliquet. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet. Nullam quis risus eget urna mollis ornare vel eu leo.</p>

</body>
</html>

Here’s how it looks:

We want to tween those properties, to make them run smoothly. We want to tween both the color, and the background-color of the nav elements, but for the inline text, we only want to tween the underline. We do this by adding the following to our style definition:

/*
 
 CSS TRANSITIONS 
 */
 
 .nav a
 {
 -o-transition: all 500ms;
 -moz-transition: all 500ms;
 -webkit-transition: all 500ms;
 transition: all 500ms;
 }
 
 p a
 {
 -o-transition: border-bottom 250ms;
 -moz-transition: border-bottom 250ms;
 -webkit-transition: border-bottom 250ms;
 transition: border-bottom 250ms;
 }

And here’s the result:

Do you use CSS3 Transitions? What effects have you been able to create? Let us know in the comments.

Featured image/thumbnail, motion image via Shutterstock.

2000+ Royalty-Free Cartoon Vectors – only $27!

The Media Annotations Working Group has published a 3rd Last Call Working Draft of API for Media Resources 1.0. This specification defines an API to access metadata information related to media resources on the Web. The overall purpose is to provide developers with a convenient access to metadata information stored in different metadata formats. The API provides means to access the set of metadata properties defined in the Ontology for Media Resources 1.0 specification. These properties are used as a pivot vocabulary in this API. The core of this specification is the definition of API interfaces for retrieving metadata information in synchronous and asynchronous. It also defines interfaces for structured return types along with the specification of the behavior of an API implementation. Comments are welcome through 03 June. Learn more about the Video in the Web Activity.

The RDF Working Group and the JSON-LD Community Group have published two Last Call Working Drafts today:

• JSON-LD 1.0. JSON-LD harmonizes the representation of Linked Data in JSON by describing a common JSON representation format for expressing directed graphs; mixing both Linked Data and non-Linked Data in a single document. The syntax is designed to not disturb already deployed systems running on JSON, but provide a smooth upgrade path from JSON to JSON-LD. It is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Linked Data Web services, and to store Linked Data in JSON-based storage engines. JSON-LD is capable of serializing any RDF graph or dataset and most, but not all, JSON-LD documents can be directly transformed to RDF.
• JSON-LD 1.0: Algorithms and API. The JSON-LD 1.0 Algorithms and API specification describes useful Algorithms for working with JSON-LD data. It also specifies an Application Programming Interface that can be used to transform JSON-LD documents in order to make them easier to work with in programming environments like JavaScript, Python, and Ruby.

This is a Last Call publication for both specifications. All substantive technical work on the specification is complete. Feedback on both specifications is encouraged and should be sent to public-rdf-comments@w3.org. The Last Call period will end in 4 weeks, on May 10th 2013

Learn more about the Semantic Web Activity and W3C Community Groups.

The MultilingualWeb-LT Working Group has published an updated working draft of Internationalization Tag Set (ITS) Version 2.0. The Internationalization Tag Set (ITS) 2.0 enhances the foundation to integrate automated processing of human language into core Web technologies. ITS 2.0 provides metadata to foster the adoption of the multilingual Web. The draft reflects changes since the last call publication 6 December 2012 and asks for feedback on the remaining open issues. Learn more about the Internationalization Activity.

The Web Applications Working Group has published a Working Draft of Clipboard API and events. This document describes APIs for clipboard operations such as copy, cut and paste in web applications. Learn more about the Rich Web Client Activity.