Ask A Pro at the 2012 WMC Fest

This year’s WMC Fest will feature an “Ask A Pro” table where students, young designers and freelancers can have their design industry questions answered. The table will feature a number of local creative leaders that have years of experience and insights to share with you. So, bring your portfolios, bring your questions and most importantly – bring your passion!

What: Ask A Pro: Portfolio Review and Industry Insights

Where: Saigon Plaza, 5400 Detroit Ave., Cleveland, Ohio 44102

When: Saturday and Sunday June 9th & 10th

Time: Noon – 2pm. *Only 2 hours each day!*

Subjects covered: Portfolio Reviews, Design Tips, Illustration Instruction, Tips for Getting Hired, Legal/Accounting questions, Freelancer Business Questions, Layout tips, Art Direction,

The Pros

William A. Beachy, President of Go Media Inc.

William is a lifelong illustrator, professionally trained graphic designer and serial entrepreneur. William earned a Bachelor’s of Science in Industrial Design from the Ohio State University. Upon graduation he started Graphic Odysseys, an illustration studio. After two years, he took a job with Cleveland Coin, where he worked as lead designer, webmaster and assistant to the marketing director. In 2000 William re-launched his company with a focus on design services. In 2002 Graphic Odysseys merged with Next Level Multimedia to become Go Media. Over the last 10 years, as president, William has grown Go Media to 13 employees and purchased a warehouse office in Cleveland’s historic Ohio City neighborhood. Their web properties include a successful design blog, a project management system, a design mock-up application and a store of digital products which boasts over 75,000 customers. Go Media’s design clients include American Greetings, Adobe, Progressive, Jim Beam and Ubisoft.

Bill’s areas of expertise: Illustration, Branding, Adobe Illustrator, Print Design, UI/UX Design, Ergonomics, Web Design, Business Strategy, Business Management, Entrepreneurship, New Business Development, Brand Strategy, Social Media Marketing.

Connie Ozan,

Connie is the founder & creative director of Twist Creative Inc.

Todd Saperstein

Todd is the Graphic Design Department Chair, Digital Media Department Chair Virginia Marti College of Art and Design.

[He] is a graduate of the Cleveland Institute of Art with a Bachelor of Fine Arts Degree in Illustration. He recently completed his Master of Arts Degree at Full Sail University in the Education Media Design and Technology program, which focused on new media and technology for use in education and business communication. He specialized in virtual learning environments and social networks, both personal and professional.

Charity D’amato

A graduate of Syracuse University with a BA in Communication Design and Art Education, Charity is the founder of Chartreuse and works alongside each and every client to ensure the best experience and design outcome. “I really adore the fact that I get to come to work everyday and be creative.” If she had to pick her favorite typeface is would be Mrs. Eaves and the more glitter in a project the better. Charity is a Cleveland Bridge Builders graduate as well as the 2010 Inside Business Athena Young Professional Award Winner.

Weapons of Mass Creation Fest 3 – Ask A Pro is a post from: GoMediaZine

Go Media is a creative agency based in Cleveland, Ohio. Besides the GoMediaZine, we also work for clients and sell stock artwork and design files on the Arsenal.

There are dozens of JavaScript testing frameworks, but most of them function in, more or less, the same way. However, Douglas Crockford’s JSCheck is considerably different from most. In this tutorial, I’ll show you how it’s different and why you should consider using it!

Crockford describes JSCheck as a “specification-driven testing tool.

Crockford describes JSCheck as a “specification-driven testing tool.” When using the frameworks you’re used to, you would write a test for a given piece of functionality, and, if that test passes, declare that the given functionality is working correctly. However, it’s possible that you might miss some of edge cases or exceptions that your tests don’t cover.

While uncovering edge cases isn’t the express purpose of JSCheck, it is a nice side benefit. The main idea behind JSCheck is this: the specification you write will actually describe how the code you are testing should work. Then, JSCheck will take that specification (called a claim in JSCheck-lingo), and generate random tests to prove the claim. Finally, it will report the results to you.

Sounds interesting? Read on! Sounds familiar? You might have used the Haskell testing tool, QuickCheck, on which JSCheck was based.

Some Code to Test

Of course, before actually writing our claim, we’ll want to have some code to test. Recently, I wrote a mini-password scorer, similar to the functionality on HowSecureIsMyPassword.net. It really isn’t fancy: you just pass the function a password and get a score back. Here’s the code:

passwordScorer.js

(function () {
    var PasswordScorer = {};

    PasswordScorer.score = function (password) {
        var len = password.length,
            lengthScore = 0,
            letterScore = 0,
            chars = {}

        if      (len >= 21) { lengthScore = 7; }
        else if (len >= 16) { lengthScore = 6; }
        else if (len >= 13) { lengthScore = 5; }
        else if (len >= 10) { lengthScore = 4; }
        else if (len >=   { lengthScore = 3; }
        else if (len >=  5) { lengthScore = 2; }

        var re = [ null, /[a-z]/g, /[A-Z]/g, /\d/g, /[!@#$%\^&\*\(\)=_+-]/g];

        for (var i = 1; i < re.length; i++) {
            letterScore += (password.match(re[i]) || []).length * i;
        }

        return letterScore + lengthScore;
    };

    (typeof window !== 'undefined' ? window : exports).PasswordScorer = PasswordScorer;
}());

It’s pretty simple code, but here’s what’s going on: the score is made up of two sub-scores. There’s a starting score, that’s based on the length of the password, and then an additional score for each character, 1 point for each lowercase letter, 2 points for each uppercase letter, 3 points for each number, and 4 points for each symbol (from a limited set).

So, this is the code we’re going to test: we’ll randomly generate some passwords with JSCheck and make sure they get an appropriate score.

Writing our Claim

Now we’re ready to write our claims. First, head over the JSCheck Github page and download the jscheck.js file. I like to run my tests in the terminal, via NodeJS, so add this single line to the very bottom of the file:

(typeof window !== 'undefined' ? window : exports).JSC = JSC;

This won’t affect the way the file behaves in the browser at all, but it will make it work as a module within Node. Notice that the jscheck.js file exposes JSC as the single global variable for the whole library. If we weren’t making this adjustment, that’s how we’d access it.

Let’s open passwordScorerSpec.js and start things:

JSC = require("./../vendor/jschec";).JSC;
PasswordScorer = require("./../lib/passwordScore";).PasswordScorer;

Since I’m running these tests in NodeJS, we’ll have to require the modules we want. Of course, you’ll want to make sure that paths match your file locations.

Now, we’re ready to write our first claim. Of course, we use the JSC.claim method. This method accepts three parameters, with an optional fourth. The first parameter is just a string, a name for the claim. The second parameter is called the predicate: it’s the actual testing function. Very simply, this function should return true if the claim is true, and false if the claim is false. The random values that JSCheck will generate for the test will be passed as parameters to the predicate.

But how does JSCheck know what type of random values to hand the predicate? That’s where the third parameter, the specifier comes into play. This is an array, with an item for each parameter for predicate. The items in the array specify what types to give the predicate, using JSCheck’s specifier functions. Here are a few of them:

• JSC.boolean() returns either true or false.
• JSC.character() takes a min and max character and returns a single character from that range. It can also take a single character code and return that character.
• JSC.integer() will return a prime number. Or, pass it a single parameter to get an integer (whole number) between 1 and the parameter, or two parameters for an integer in that range.

You get the idea. There are other specifiers, and we’ll use some now as we write our first claim.

JSC.claim("All Lowercase Password";, function (password, maxScore) {
  return PasswordScorer.score(password) <= maxScore;
}, [
  JSC.string(JSC.integer(10, 20), JSC.character('a', 'z')),
  JSC.literal(26)
]);

Our first parameter is a name. The second is the testing function: it receives a password and a max score, and returns true if the score for that password is less than or equal to the max score. Then, we have our specifier array. Our first parameter (the password) should be a string, so we use the JSC.string() method: it can take two parameters, the number of characters in the string, and value for those characters. As you can see, we’re asking for a password between 10 and 20 characters. For the value, we’re using the JSC.characters() method to get random characters between ‘a’ and ‘z’.

The next value is our maxScore parameter. Sometimes, we don’t want the randomness that JSCheck offers, and this is one of those times. That’s why there’s JSC.literal: to pass a literal value the predicate. In this case, we’re using 26, which should be the max score for any all-lowercase password between 10 and 20 characters.

Now we’re ready to run the test.

Running our Claim

Before we actually run the claim and get the report, we have to setup the function that will receive the report. JSCheck passes the report to a callback function of JSC.on_report. Hence:

JSC.on_report(function (str) {
  console.log(str);
});

Nothing fancy. Now, all that’s left is to call JSC.check(). Now, we can head to our terminal and run this:

node path/to/passwordScorerSpec.js

Behind the scenes, JSCheck runs the predicate 100 times, generating different random values each time. You should see your report printed out.

All Lowercase Passwords 100 of 100
 pass 100

They all passed, but that’s not much of a report, eh? Well, if any of our tests had failed, they would have been included in the report. However, you can adjust the level of output with the JSC.detail function: pass it a number between 0 and 4 (inclusive) to get anything for no output to all the test cases. The default value is 3.

Adding a Classifier

Remember how I said that JSC.claim could take a fourth parameter? It’s called a classifier, and it receives the same parameters that the predicate receives. Then, it can returns a string to classify, or group, our test cases. I’ll admit I wasn’t really sure where this would be useful until I was creating the above example claim. See, I made a mistake in the predicate and compared the score to the maxScore with the < operator instead of the <= operator, so any passwords that scored 26 points were failing. I was seeing reports that looked something like this:

All Lowercase Passwords 96 of 100
 FAIL [12] ("vqfqkqqbwkdjrvplkrx";,26)
 FAIL [21] ("nhgkznldvoenhqqlfza";,26)
 FAIL [62] ("eclloekuqhvnsyyuekj";,26)
 FAIL [78] ("rvrkfivwtdphrhjrjis";,26)
 pass 96 fail 4

It’s still entirely obvious why some tests are failing. So I added a classifier function that grouped the test cases by score: like I said, the function takes the same parameters as the predicate, and it returns a string. Every test case that gets the same string back from the classifier will be grouped together in the report.

function (password, maxScore) {
	return PasswordScorer.score(password) + " points";;
}

This function should be the last parameter of our claim. Now, you’ll get a report that’s something like this:

All Lowercase Passwords 96 of 100
 FAIL [4] 26 points:("illqbtiubsmrhxdwjfo";,26)
 FAIL [22] 26 points:("gruvmmqjzqlcyaozgfh";,26)
 FAIL [34] 26 points:("chhbevwtjvslprqczjg";,26)
 FAIL [65] 26 points:("kskqdjhtonybvfewdjm";,26)
14 points: pass 8
15 points: pass 5
16 points: pass 12
18 points: pass 10
19 points: pass 12
20 points: pass 11
22 points: pass 12
23 points: pass 8
24 points: pass 10
25 points: pass 8
26 points: pass 0 fail 4

You can see how the tests are grouped by how many points the passwords are worth. Now, it’s easy to see that the only passwords that fail the tests are the passwords that score 26 points. And while the problem here was with the test, and not the code, it still shows how it can be useful to add a classifier function to your claims.

Final Thoughts

So, at the end of the day, it JSCheck worth using? Here’s what I think: it’s not something you’re necessarily going to use with every code base, but sometimes you’ll find it useful to be able to create random test cases that will rigorously test a given piece of code. When that’s what you want to do, I haven’t seen a tool better for that than JSCheck.

JSCheck has a few other options and a bunch of specifiers that we haven’t reviewed in this tutorial; head over to JSCheck.og to read about those. Otherwise, I’d love to hear your thoughts about JSCheck in the comments!

Calls and Screen Sharing

Join.me
It’s simple, easy, and free. Either join someone’s screen share or share your own. You can invite up to 250 viewers into your screen share and can even let them take control of your computer. Join.me has a great list of features, such as internet calling, chat, and file sharing, which makes it a great all-in-one solution for screen sharing presentations.

Skype
Skype has over 600 million users, so chances are high that even your client will have an account that he/she can hop on to at any time. Skype is a great way to have face-to-face conversations with clients when the option of meeting them in person is unavailable. In addition, if you need to chat with more than one person in a single call, Skype comes with conference call support so you can include as many people as you want in your presentation. Most importantly, Skype has a built-in screen sharing ability that allows you to switch from video to design comp with ease.

GotoMeeting
GotoMeeting is a familiar business go-to for conference calls and screen shares. You can attend meetings from your phone or your computer and utilize its convenient scheduling features to help better organize your meetings and presentations.

Google Video Chat
You probably already have your Gmail inbox open, so why not hop on a video or audio call with your clients within the same workspace? If you live in your Gmail inbox archives and frequently reference email exchanges and attachments in your workflow, Google Video is the perfect solution for communicating with your clients.

Google Voice
This is a frequently underrated communication tool that makes living our work lives on computers that much easier. Free up your hands by using your computer as your phone. Even if you miss a call, you can easily access it via Google voicemail or email transcription!

Presenting: Information Architecture and Prototypes

Axure
Axure is a powerful and robust flowcharting, wireframing, and prototyping tool for all of your IA and prototyping needs. Axure is easy to use and is packed with every sort of web tool imaginable for creating the web wireframe or prototype of your dreams. You can even utilize its dynamic panels and widgets (including user-created widgets) to make your prototypes interactive. And if you want to get even more complex with your prototypes, you can integrate APIs and data to make your prototypes work with remote data!

Mockingbird
If you’re looking for an inexpensive, browser-based solution, Mockingbird is the way to go. If you’re working with a team, everyone can access and work on your wireframes together. Previewing and sharing your wireframes is easy, and since everything is online, you’ll avoid having to deal with more file organization and clutter. To make things even easier, Mockingbird has an intuitive UI, with simple drag-and-drop interactions, smart text resizing, and interactive page linking.

Omnigraffle
Omnigraffle is a great Mac solution for creating and presenting flowcharts, sitemaps, and wireframes. While it comes with a great span of tools to create your IA needs, it really shines with its “stencils” feature. For a fully customizable and personalized look, you can utilize Omnigraffle’s stencil or user-created libraries.

InVision
Want to create beautiful wireframes and prototypes? InVision is a simple and intuitive web application that allows you to take your design jpgs, pngs, or gifs and turn them into interactive prototypes within minutes. You’ll be amazed at how easy it is to turn your flattened PSD images into dazzling working prototypes.

Presenting: Designs

Photoshop full view mode and layer comps
Did you know you can utilize the different screen modes in Photoshop to view your PSD file? Photoshop’s Full Screen view hides everything but whatever is on your canvas and allows for easy toggling access back to the PSD in case you want to edit some nitty gritty elements of your file. Another great way to present designs is to use Photoshop layer comps. Layer comps allow you to save specific visibility, position, and layer styles for different versions or parts of your design. These layer comps are saved to your PSD so you can come back to them at any time.

Preview for Mac
If you’re using a Mac, Preview is a powerful default image viewer that allows for easy viewing of your jpgs, pngs, and pdfs. If you have Lion OS X installed, you can take preview one step further by taking advantage of the revamped Slideshow or Full Screen modes. These two modes have the same functions as Preview normally does, but they’re now packed with beautiful isolated presentation screens that allow you to swipe between multiple images in a subtle but showy sliding interaction.

Picasa Photo Viewer for PC
While Windows Picture and Fax viewer has some merit to its usability, a great image viewing app that you might want to consider installing on your PC is the Picasa Photo Viewer. It’s got a great interface for navigating through files, and its black overlay background makes viewing a single design (PSD or image file) both clean and easy.

Browser Viewing
For web-based projects, another interesting way to present a design is to drag your image file straight into your internet browser. This gives your clients the experience of seeing your design in its natural environment and helps capture a better overall impression of how the design will feel. Also, if you’re HTML/CSS savvy, you can make edits with the browser’s “Inspect element” screen to center and throw a background color behind your image. You’ll hardly be able to tell that the design isn’t live!

Feedback and Collaboration Tools

Notable
Notable app allows your clients to give feedback straight onto the designs themselves (image files only). What’s especially nice about Notable is that feedback is displayed as an overlayed highlight area that clearly indicates what parts of the design are being discussed. You can then have a threaded conversation on that feedback or even create your own notes on your design.

InVision
InVision was mentioned earlier for its wireframing and prototyping capabilities, but it also allows for collaborative feedback on these projects. So not only will you have beautiful IA and designs to show your client, you can also ask them make comments right on your InVision mockups.

Basecamp
Basecamp is one of the most popular project management systems on the web. Apart from its project management system, however, is its feedback environment for designs and PSDs. Since many of your clients will probably be familiar with Basecamp, having them provide their feedback within the app itself will be beneficial for both of you. This helps you keep your project organized, recorded, and easily accessible. If you’re looking for free alternatives that yield similar results, take a look at Freedcamp and Podio.

Google Docs
Free and popular, Google Docs is a great area for storing feedback on Word docs, Excel sheets, and many other document types. Google Docs has a particularly useful commenting system which allows for easy comment threading and discussion. Especially if your clients enjoy giving written feedback, consider taking advantage of this online resource.

About the Author:

Jessica Moon is both the blog editor and a UX/UI designer at digital-telepathy, a user experience design studio that specializes in creating products like SlideDeck, Hello Bar, and Impress. She has a passion for illustration and design, and enjoys blogging and sharing what she’s learned via Twitter and Google+.

Direct Link to Article — Permalink

Responsive Images and Web Standards at the Turning Point is a post from CSS-Tricks

Advertise here via BSA

Javascript lacks complete string manipulation operations. Underscore.string attempts to fill that gap. Underscore.string is JavaScript library for comfortable manipulation with strings, extension for Underscore.js inspired by Prototype.js, Right.js, Underscore and beautiful Ruby language.

Underscore.string provides you several useful functions: capitalize, clean, includes, count, escapeHTML, unescapeHTML, insert, splice, startsWith, endsWith, titleize, trim, truncate and so on. It is released under MIT License.

Requirements: JavaScript Framework
Demo: http://epeli.github.com/underscore.string/
License: MIT License

Sponsors

Professional Web Icons for Your Websites and Applications

Did you all enjoy creating iPad cases for our Zazzle contest? I hope so. There were so many fabulous entries, you guys are great at creating some inspiring pieces. So thank you for entering.

Today we are here to announce the winners of the Zazzle contest.

• Grand prize winner will receive $500 + a copy of their winning iPad Sleeve
• 1 Runner-up will receive $100 Zazzle gift certificate + copy of their iPad Sleeve
• 2 Honorable mentions will receive $50 Zazzle gift certificates + copies of their iPad Sleeves

The runner-up who will be receiving a $100 Zazzle gift certificate + copy of their iPad Sleeve is: Vintage Flowers iPad Sleeve by HazelAgnes.

The 2 Honorable mentions who will be receiving a $50 Zazzle gift certificates + copies of their iPad Sleeves: PATTERN {chevron 011} by Schatzibrown

And finally, Vintage Floral by pinkinkstudio

Congrats to all the winners! Thank you so much to everyone who entered the Zazzle contest. I hope you had a lot of fun with this contest and we are excited to keep bringing you more.

Really short answer: SASS

Slightly longer answer: SASS is better on a whole bunch of different fronts, but if you are already happy in LESS, that’s cool, at least you are doing yourself a favor by preprocessing.

Much longer answer: Read on.

The Much Longer Answer

The Learning Curve with Ruby and Command Line and Whatever

The only learning curve is the syntax. You should use an app like CodeKit to watch and compile your authored files. You need to know jack squat about Ruby or the Command Line or whatever else. Maybe you should, but you don’t have to, so it’s not a factor here.

Winner: Nobody

Helping with CSS3

With either language, you can write your own mixins to help with vendor prefixes. No winner there. But you know how you don’t go back and update the prefixes you use on all your projects? (You don’t.) You also won’t update your handcrafted mixins file. (Probably.) In SASS you can use Compass, and Compass will keep itself updated, and thus the prefix situation is handled for you. Yes you’ll have to keep your local preprocessor software updated and compile/push once in a while, but that’s trivial and thinking-free.

So what this comes down to is: SASS has Compass and LESS does not. But it goes deeper than that. The attempts at creating a real robust project like Compass for LESS haven’t succeeded because the LESS language isn’t robust enough to do it properly. More on that next.

Winner: SASS

Language Ability: Logic / Loops

LESS has an ability to do “guarded mixins.” These are mixins that only take affect when a certain condition is true. Perhaps you want to set a background color based on the current text color in a module. If the text color is “pretty light” you’ll probably want a dark background. If it’s “pretty dark” you’ll want a light background. So you have a single mixin broke into two parts with these guards that ensure that only one of them takes effect.

.set-bg-color (@text-color) when (lightness(@text-color) >= 50%) {
  background: black;
}
.set-bg-color (@text-color) when (lightness(@text-color) < 50%) {
  background: #ccc;
}

So then when you use it, you’ll get the correct background:

.box-1 {
  color: #BADA55;
  .set-bg-color(#BADA55);
}

That is overly simplified, but you likely get the idea. You can do some fancy stuff with it. LESS can also do self-referencing recursion where a mixin can call itself with an updated value creating a loop.

.loop (@index) when (@index > 0) {
  .myclass {
    z-index: @index;
  }
  // Call itself
  .loopingClass(@index - 1);
}
// Stop loop
.loopingClass (0) {}

// Outputs stuff
.loopingClass (10);

But thats where the logic/looping abilities of LESS end. SASS has actual logical and looping operators in the language. if/then/else statements, for loops, while loops, and each loops. No tricks, just proper programming. While guarded mixins are a pretty cool, natural concept, language robustness goes to SASS. This language robustness is what makes Compass possible.

For example, Compass has a mixin called background. It’s so robust, that you can pass just about whatever you want to that thing that it will output what you need. Images, gradients, and any combination of them comma-separated, and you’ll get what you need (vendor prefixes and all).

This succinct and intelligible code:

.bam {
  @include background(
    image-url("foo.png"),
    linear-gradient(top left, #333, #0c0),
    radial-gradient(#c00, #fff 100px)
  );
}

Turns into this monster (which is unfortunately what we need for it to work with as good of browser support as we can get):

.bam {
  background: url('/foo.png'), -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #333333), color-stop(100%, #00cc00)), -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #cc0000), color-stop(100%, #ffffff));
  background: url('/foo.png'), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -ms-linear-gradient(top left, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), linear-gradient(top left, #333333, #00cc00), radial-gradient(#cc0000, #ffffff 100px);
}

Winner: SASS

Website Niceitude

LESS has a nicer, more usable website. The SASS documentation isn’t awful. It’s complete and you can find what you need. But when competing for attention from front end people, LESS has the edge. I don’t doubt this plays a large role in LESS currently winning the popularity race. Things may be changing though.

Winner: LESS

The @extend Concept

Say you declare a class which has a bit of styling. Then you want another class which you want to do just about the same thing, only a few additional things. In LESS you’d likely:

.module-b {
   .module-a(); /* Copies everything from .module-a down here */
   border: 1px solid red;
}

That’s an “include” essentially. A mixin, in both languages. You could use an include to do that SASS as well, but you’re better off using @extend. With @extend, the styles from .module-a aren’t just duplicated down in .mobule-b (what could be considered bloat), the selector for .module-a is altered to .module-a, .module-b in the compiled CSS (which is more efficient).

.module-a {
   /* A bunch of stuff */
}
.module-b {
   /* Some unique styling */
   @extend .module-a;
}

Compiles into

.module-a, .module-b {
  /* A bunch of stuff */
}
.module-b {
  /* Some unique styling */
}

See that? It rewrites selectors, which is way more efficient.

Winner: SASS

Variable Handling

LESS uses @, SASS uses $. The dollar sign has no inherit meaning in CSS, while the @ sign does. It’s for things like declaring @keyframes or blocks of @media queries. You could chalk this one up to personal preference and not a big deal, but I think the edge here is for SASS which doesn’t confuse standing concepts.

SASS has some weirdness with scope in variables though. If you overwrite a “global” variable “locally”, the global variable takes on the local value. This just feels kind of weird.

$color: black;
.scoped {
  $color: white;
  color: $color;
}
.unscoped {
  // LESS = black (global)
  // SASS = white (overwritten by local)
  color: $color;
}

I’ve heard it can be useful but it’s not intuitive, especially if you write JavaScript.

Winner: Tossup

Working with Media Queries

The way most of us started working with @media queries was adding blocks of them at the bottom of your main stylesheet. That works, but it leads to mental disconnect between the original styling and the responsive styles. Like:

.some-class {
   /* Default styling */
}

/* Hundreds of lines of CSS */

@media (max-width: 800px) {
  .some-class {
    /* Responsive styles */
  }
}

With SASS or LESS, we can bring those styles together through nesting.

.some-class {
  /* Default styling */
  @media (max-width: 800px) {
    /* Responsive styles */
  }
}

You can get even sexier with SASS. There is a really cool “respond-to” technique (see code by Chris Eppstein, Ben Schwarz, and Jeff Croft) for naming/using breakpoints.

=respond-to($name)

  @if $name == small-screen
    @media only screen and (min-width: 320px)
      @content

  @if $name == large-screen
    @media only screen and (min-width: 800px)
      @content

The you can use them succinctly and semantically:

.column
    width: 25%
    +respond-to(small-screen)
      width: 100%

Note: requires SASS 3.2, which is in alpha, which you can install with gem install sass --pre. I don’t think there is any doubt this is a very nice way to work.

Winner: SASS

Math

For the most part, the math is similar, but there are some weirdnesses with how units are handled. For instance, LESS will assume the first unit you use is what you want out, ignoring further units.

div {
   width: 100px + 2em; // == 102px (weird)
}

In SASS, you get a clear error: Incompatible units: ‘em’ and ‘px’. I guess it’s debatable if it’s better to error or be wrong, but I’d personally rather have the error. Especially if you’re dealing with variables rather than straight units and it’s harder to track down.

SASS will also let you perform math on “unknown” units, making it a bit more futureproof should some new unit come along before they are able to update. LESS does not. There is some more weird differences like how SASS handles multiplying values that both have units, but it’s esoteric enough to not be worth mentioning.

Winner: Narrowly SASS

Active Development

At the time of this writing…

Number of open issues on LESS: 392
Number of open issues on SASS: 84

Pending pull requests on LESS: 86
Pending pull requests on SASS: 3

Number of commits in the last month in LESS: 11
Number of commits in the last month in SASS: 35

None of that stuff is any definitive proof that one project is more active than the other, but the numbers do seem to always leans toward SASS. As I understand it, both of the leads work on the languages in whatever little free time they have, as they both have other major new projects they are working on.

Winner: Probably SASS

More Reading

• Chris Eppstein: SASS/LESS Comparison
• Jeremy Hixon: An Introduction To LESS, And Comparison To Sass
• Ken Collins: Too LESS? Should You Be Using Sass?
• Johnathan Croom: Sass vs. LESS vs. Stylus: Preprocessor Shootout

SASS vs. LESS is a post from CSS-Tricks

Adaptive images are the next unsolved mystery of Responsive Web Design. Do you send large high-res images suitable for retina dispays, which are scaled down on smaller, lower res devices and which therefore waste bandwidth? Or do you send low-res images, whch look grotty when scaled up to large screens or high-res displays? Authors have had to rely on elaborate hacks to send different content images (that is <img> in HTML rather than CSS background images) to different types of devices.

By November 2011, I was so frustrated that no specification body was considering the problem that I proposed a strawman <picture> element that re-used the mechanism of HTML5 <video> with its media queries to swap in different source files:

<picture alt="angry pirate">
   <source src=hires.png media="min-width:800px">
   <source src=midres.png media="min-width:480px">
   <source src=lores.png>
      <!-- fallback for browsers without support -->
      <img src=midres.png alt="angry pirate">
</picture>

Around the same time, others independently came to the same idea and were advised to set up a W3C community group to discuss it which they did. However, in January, the HTML5 editor, Ian Hickson, had said

What’s the use case for doing it for images in <img> elements? Typically <img> elements are for content images, where you don’t usually want to adapt anything.

Those web authors in the W3C Resposive Images Community Group soldiered on in frustration that they were they being ignored because the problem itself wasn’t seen as a problem. Then this week, Edward O’Connor of Apple suggested another method, using a new srcset attribute on the <img> element. This complemented a similar suggestion of his from February for img-set in CSS that is already being added to WebKit:

<img src="foo-lores.jpg"
     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
     alt="decent alt text for foo.">

The numbers “2″ and “6.5x” tell the browser the relative resolutions; foo-hires.jpg is 2x the resolution of foo-lores.jpg.

Only a few days later, a variant of Apple’s suggestion was added to the spec.

There are two major differences between <picture> and srcset. The most obvious is that srcset uses the <img> element, which is great because that’s the natural place for images, adaptive or not. (You can’t re-use the <video> + <source> pattern with <img> because it is an empty element so can’t have child elements. O’Connor’s solution uses attributes, which are fine.)

The other major difference is that it doesn’t use Media Queries. With Media Queries, the author is reponsible for thinking up every permuations of viewport size, orientation, dpi, colour depth, aspect ratio and the like, deciding how to cater for them (if at all), identifing the breakpoints and coding them up. This requires a lot of consideration by the author, and makes for verbose code; a page with 20 pictures, each with 5 Media Queries on 5 <source> elements quickly becomes a lot of code.

O’Connor wrote

Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we’re asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just “media-queriable things” like device resolution but also any scaling applied to the <img> with CSS, its width=”” and height=”” attributes, or even things like the current page zoom level.

I have a lot of sympathy with allowing the browser to make decisions about what it knows of the environment (network speed, latency, pixel density, orientation) to choose the best image for the job. The idea is that the author shouldn’t be expected to anticipate and cater for all those variables. What she can do is describe the things she knows about -the images, their size and pixel density- and the browser will make its choice.

That way, when we’re all living in space and looking a 3D holograms, the proximity to a black hole can be detected by the iDroid3000 device (black holes notoriously cause Web hologram negative timespace inversions) and the right image chosen; we don’t need to invent new media queries for event horizon proximity and retrospectively add it to our websites.

There are two problems with the srcset suggestion. The first is highly subjective, but many feel the same: as it exists in the current, first draft of the spec, the syntax is revolting:

<img src="face-600-200-at-1.jpeg" alt=""
srcset="face-600-200-at-1.jpeg 600w 200h 1x,
face-600-200-at-2.jpeg 600w 200h 2x,
face-icon.png 200w 200h">

Of course, this can be improved, and must be. This isn’t just about aesthetics. If the syntax is too weird, it will be used wrongly. As Dr Remy wrote, “Good to see authors have another microsyntax to learn. It’s not like they had any trouble with vendor-prefixes.”

The second problem is that authors don’t want to relinquish control. There are questions of art direction (see the section headed Do I care about art direction?), and many remain unconvinced that the Apple suggestion addresses that; proponents of srcset are convinced that it does address those use cases.

Debate continues, with a full and frank exchange of views. There are understandably hurt feelings, too, because some of those who laboured in the Community Group feel that their wishes and work have been ignored.

As one of those who proposed <picture>, I have a degree of attachment to it. That’s ego. (In fact, I’d be delighted if it were called the <yayBruce> element, but I’m resigned to the unfairness of life.) But I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So, get involved. Read the discussions and say your piece. And once the dust has settled and the specification is looking stable, we Doctors will write up our diagnosis.

HTML5 adaptive images: end of round one originally appeared on HTML5 Doctor on May 16, 2012.

Then a few months ago, in response to an article here, a W3C Responsive Images Community Group formed—and proposed a simple-to-understand HTML picture element capable of serving responsive images. The group even delivered picture functionality to older browsers via two polyfills: namely, Scott Jehl’s Picturefill and Abban Dunne’s jQuery Picture. The WHATWG has responded by ignoring the community’s work on the picture element, and proposing a more complicated img set element.

Which proposed standard is better, and for whom? Which will win? And what can you do to help avert an “us versus them” crisis that could hurt end-users and turn developers off to the standards process? ALA’s own Mat Marquis explains the ins and outs of responsive images and web standards at the turning point.

This tutorial will help you prepare a Magento install for high traffic, better load times, and simpler ongoing site management. Ready?

Requirements

You can download the finished code for this tutorial, or launch the “magento-basic” Quickstart from your Pagoda Box account to test a working site.

• A Pagoda Box Account (free)
• A functional local Magento Install
• Local Development Software (MAMP or WAMP)
• Git Installed (Can use SFTP)
• The Pagoda Terminal Client Installed

Fair Warning: This tutorial may change your life. Pagoda Box is not traditional hosting. The teachings in this article will not only help scale Magento, but it alos lays the groundwork for a progressive development-to-production workflow.

Step 1: Set Up Git Locally (SFTP will work as an alternate)

Note: If you already use Git, you can skip this section. If not, the guide Setting Up Git provides specific instructions for creating an SSH Key, as well as links for downloading and installing Git (also below).

While it is possible to use just SFTP on Pagoda Box, the officially recommended (and most efficient) workflow integrates Git into your daily development. Git enables features like collaboration, uniform code distribution, deploys, deploy history and rolling back code. While most of these features are available to FTP users, using Git makes integration seamless.

If you want to fully take advantage of Pagoda Box, download Git, and Learn the Basics. Depending on your operating system, set up may vary slightly. Regardless of your OS, the commands are identical once Git is installed.

Using Git to manage collaboration and version control may involve a brief learning curve. However, there are generally only three commands we’ll use on an ongoing basis to commit changes locally, then deploy to Pagoda Box:

• git add . – Adds local files to your repository
• git commit -m "some message about what you've done" – Commits your changes
• git push pagoda --all – Pushes changes to Pagoda Box Repository (auto-deployed by default)

We’ll use these later.

Step 2: Install the Pagoda Box Terminal Client

                             *
                           /   \
                         /       \
                     +_/ / / | \ \ \_+
                         ||*|||*||
                         |+||*||+|
                         /       \
                     +_/ / / | \ \ \_+
                         ||*|||*||
                         |+||*||+|
     ____   _    ____  ___  ____    _    ____   _____  __
    |  _ \ / \  / ___|/ _ \|  _ \  / \  | __ ) / _ \ \/ /
    | |_) / _ \| |  _| | | | | | |/ _ \ |  _ \| | | \  /
    |  __/ ___ \ |_| | |_| | |_| / ___ \| |_) | |_| /  \
    |_| /_/   \_\____|\___/|____/_/   \_\____/ \___/_/\_\

       Welcome To Your Pagoda Box Terminal Client.
      -----------------------------------------------
          -----------------------------------------
             ---------------------------------
                          Enjoy.

Pagoda Box provides a Terminal Client that lets you clone, create, deploy, destroy, rename and rollback an application from the command line. Later in this tutorial, we’ll use the client to create a secure tunnel to the live Magento database with Sequel Pro (the process is similar for other database managment tools like HeidiSQL).

The Pagoda Box Terminal Client is a rubygem, so installation is pretty simple. First off, Ruby needs to be installed. Installation is different for each operating system.

• Mac – Ruby and RubyGems come pre-installed on Mac OSX. As long as you are running v10.5 or later, you should be good to go.
• Windows – There are a couple of different ways to install Ruby in Windows. We recommend this auto-installer. If it doesn’t work for your set-up, a Google search will give you a pretty good list of installation walk-throughs.
• Linux – Use your preferred package manager to download the Ruby package. For Ubuntu users, the gem is available through getdeb.net.

Install and Verify Terminal Client

Once Ruby is installed, simply run the following command to install the Pagoda RubyGem:

On Mac or Linux:

$ sudo gem install pagoda

On Windows:

$ gem install pagoda

Then, to verify you have the Pagoda Gem installed properly, run:

$ pagoda list

If this is the first time you’ve used the Gem, it will ask for your Pagoda Box Username and Password. After you’ve entered those, expect to see a list of your Pagoda Box applications. If you haven’t created any applications, the list will be blank.

If you get an error, it’s most likely invalid credentials. You can verify or change which credentials the gem uses by editing the file located on your local computer at ~/.pagodarc. Make sure to exactly match the credentials you use in your Pagoda Box account. (Note: this is a hidden file, so you’ll need to enable hidden files or open via the terminal. Also note that the file stores your credentials twice, so edit both if needed.)

Step 3: Install Magento Locally

Note: Skip this step if you already have a working local Magento install.

If you don’t have it already, ensure you are using local webserver and database management software. There are several options available, depending on your operating system. A common option for Mac is MAMP, or WAMP for Windows. Both are free and easily set up.

Once your local development environment is set up, go ahead and download Magento, then follow the official guide to install Magento locally.

Feel free to use Magento’s auto install script to set up the application in your local environment. However, due to Pagoda Box’s distributed cloud architecture, the script will not install Magento directly in your production environment. The Pagoda Box workflow and architecture requires you to make code modifications locally, commit, then deploy to production. This workflow accommodates collaboration and development > staging > production best practices.

Step 4: Configure PHP Using a Boxfile

Note: On Pagoda Box, a YAML Boxfile can be included in the root of your code repository. While the Boxfile is optional, it does provide advanced features, like manipulating your hosted environment on each deploy. We’ll use the Boxfile extensively in this Tutorial to simplify tasks, and to make the respository reusable on Pagoda Box.

Create a file named “Boxfile” in the root of your local Magento installation, then copy the following into your Boxfile (explanation below):

web1:
  name: mag-app
  shared_writable_dirs:
    - media
    - var
  php_version: 5.3.8
  php_extensions:
    - pdo_mysql
    - mysql
    - simplexml
    - mcrypt
    - hash
    - gd
    - dom
    - iconv
    - curl
    - soap

Create / Name the Web Cluster

This Boxfile serves several purposes. First, it creates a web1 component, then names it mag-app.

Shared Writable Directories

Second, the Boxfile identifies media and var as shared writable directories. This allows users to upload images, video, and other media to a distributed Magento cloud site without instances writing themselves out of sync.

When a directory is marked as writable, the contents are no longer deployed to Pagoda Box from your local repository. Any time local files need to be deployed to these directories, they must be manually copied via SSH or SFTP. You may also use SSH/SFTP to transfer files from Pagoda Box to your local machine as needed.

PHP Version and Extensions

The Boxfile also declares which PHP version and extensions will be included in your web instances as they deploy. This way, both the environment and the application are versioned together, so rolling back to a previous deploy includes the correct PHP version and extensions. The list of PHP extensions in this Boxfile was taken from Magento’s official system requirements.

Tip: Once Git is installed in your local environment, use the .gitignore file to ignore the writable directories specified in your Boxfile. Identifying these directories inside the .gitignore file helps reduce the size of your repo, and your deploy time. In addition to the writable directories, you can also add the downloader directory to the .gitignore file, since it’s used locally, and not on Pagoda Box.

Once you’ve installed Git and the Terminal Client, configured the Boxfile and finalized your local source code, you’re ready to launch on Pagoda Box.

Step 5: Create a Free Pagoda Box Account

If you don’t already have one, create a free Pagoda Box account. You will not need to enter a credit card to install Magento for testing.

If you have not already done so, follow this guide to Add an SSH Key in your Pagoda Box Admin panel. The guide will provide specific instructions for setting up an SSH Key on either Mac or Windows.

Step 6: Upload Magento to Pagoda Box

Once you’ve created a Pagoda Box account and set up an SSH Key, go to the Home Page in your new account and click the “New Application” button to create a new application.

Note: This tutorial names our sample application “magento”. The app name is also used for the Pagoda Box repository, the subdomain for the freshly deployed application (magento.pagodabox.com), and the username in SFTP mode. Replace “magento” with “your-app-name-here” where appropriate throughout the remainder of this tutorial.

Upload to an Empty Repo (recommended for this tutorial)

Next, choose from the 3 options to launch your Magento site. Since you already have a customized version of Magento locally, select ‘Empty Repo’ to deploy using SFTP or Git, name your application, and click “Launch Application”.

You’ll be asked to select your preferred deployment method (Git or SFTP). Click on your preference, and follow the instrutions on-screen.

Git Option

You can copy and paste the on-screen instructions from the Pagoda Box dashboard to your terminal after using Terminal to change directory (cd) to the root of your project.

The pasted commands do the following:

• git init – Initialize your Magento project as a Git Repository
• git add . – Add all files from the project to the repo
• git commit -m 'your commit message' – Commit files with a message that allows you to quickly scan deploy history in the future, in case you need to revert or modify changes
• git remote add pagoda git@git.pagodabox.com:magento.git – Add Pagoda Box as a remote (the specific git url for your application appears on both this screen, and in your app dashboard
• git push pagoda --all – Push your local code to the Pagoda Box remote repository. As long as you’re on the “master” branch (which is the default), Pagoda Box will automatically deploy your code, and carry out the instructions we set in the Boxfile. Auto-deploy can be turned off in the Admin dashboard, or configured to deploy automatically from a Git branch other than Master.

SFTP Option

If you opted for SFTP, Pagoda Box will guide you through establishing credentials and a password. Connect via SFTP to Pagoda Box, and upload your Magento source code in the code directory.

Step 7: Create a Database

There are two ways to create a database on Pagoda Box. Each has benefits, explained below:

Create a DB in the Boxfile

The Boxfile will automatically create a database component on deploy, as long as that component (db1, db2, etc.) doesn’t already exist. Declaring the database in the Boxfile saves a bit of time now, and makes deploying multiple Magento sites from a standardized code base much simpler in the future. (Note: Only cloud DBs can be deployed from the Boxfile. If you need a larger, dedicated or redundant database, see the Dashboard option later in this Step.) Add the following to your Boxfile:

db1:
  name: mag-db
  type: mysql
  

Your updated Boxfile should look like this:

web1:
  name: mag-app
  shared_writable_dirs:
    - media
    - var
  php_version: 5.3.8
  php_extensions:
    - pdo_mysql
    - mysql
    - simplexml
    - mcrypt
    - hash
    - gd
    - dom
    - iconv
    - curl
    - soap
db1:
  name: mag-db
  type: mysql
  

Then commit changes to the updated file and push changes to Pagoda Box:

$ git commit -m "pagoda config"
$ git push pagoda --all

Alternate: Create a DB in the Dashboard

You can also create a database from the Pagoda Box Dashboard. This is where you add a larger, dedicated or redundant database.

First, click “Add Database” in the Dashboard.

Pagoda Box will step through a series of screens to configure your database, depending on your choices. If you’ve chosen the Dedicated option, you will be asked to size your database as follows:

Cloud databases usually deploy within minutes. If you chosen Dedicated, don’t get impatient. You may wait for up to 90 minutes for a big server to be provisioned to your specifications.

Step 8: Configure DB Credentials for Production

Your database automatically generates credentials when it’s created on Pagoda Box. We’ll use those credentials to configure Magento in production.

However, since Magento will be used in both local environments and in production, we need to supply different database credentials for each. We’ll use Deploy Hooks in the Boxfile to simplify this process by executing scripts or commands during deploy.

In the case of Magento, we’ll swap the local.xml file upon deploy. That way, without manually switching credentials, the app/etc/local.xml file will automatically have local database credentials in development, but production database credentials on Pagoda Box.

Create a local.xml for Production

First, create a directory named pagoda in root, then copy Magento’s app/etc/local.xml to the new directory.

Next, edit local.xml to include Pagoda Box database credentials from your account dashboard. Note that Pagoda Box uses 3 levels of authentication, so that even if your credentials are compromised, other users cannot access your database.

Swap local.xml Configs on Deploy

Add the following into your Boxfile, under the web1 section to create the Deploy Hook.

after_build:
  "mv pagoda/local.xml app/etc/local.xml"

Your updated Boxfile should look like this:

web1:
  name: mag-app
  shared_writable_dirs:
    - media
    - var
  php_version: 5.3.8
  php_extensions:
    - pdo_mysql
    - mysql
    - simplexml
    - mcrypt
    - hash
    - gd
    - dom
    - iconv
    - curl
    - soap
  after_build:
  - "mv pagoda/local.xml app/etc/local.xml"
db1:
  name: mag-db
  type: mysql
  

Then commit changes and push to Pagoda Box:

$ git add .
$ git commit -m "pagoda config"
$ git push pagoda --all

Step 9: Migrate the Database

With the same tools you use to manage a local database, you can securely manage a live database on Pagoda Box. We’ll use Sequel Pro for this example, but the process is similar for tools like HeidiSQL.

Export Your Local DB

When the Magento install script ran locally, it created several tables in the local database. Those tables need to be migrated to production.

First, export your local database using your database manager: File > Export.

Now choose a location, and Save the export.

Establish a Secure DB Connection

Now establish a database tunnel. Using the Pagoda Box Terminal Client, specify the app whose database you are trying to access, and the ID of the database component (e.g. db1), as in this example:

$ pagoda -a magento tunnel -c db1
--OR--
$ pagoda --app=magento tunnel --component=db1

Once the tunnel is established, use Sequel Pro (or similar) to connect to the database using the Host and Port provided by the Pagoda Terminal Client…

And the username and password in your Pagoda database credentials. These were automatically created with your database, and may be found in the Pagoda Box Dashboard under the database component (see example in Step 8).

Import and Update the Production DB

Next, import your database into production using Sequel Pro (or similar): File > Import. Now select the database export file, and Open.

Finally, since we ran the install script locally, it’s necessary to adjust the base url directly in the database before browsing the site. While you are still connected to the Pagoda Box database in Sequel Pro, navigate/filter to the core_config_data table and edit the value for the following paths:

web/unsecure/base_url
web/secure/base_url

The values for each should look something like this:

Step 10: Configure Mail

To protect your IPs from being flagged as spam, Pagoda Box uses the SMTP mail protocol to send email via third party mail provider SMTP credentials. In English, that means you need a company (like Gmail) that provides mail services.

Regardless of which mail provider you choose, enter account credentials from that provider in your Pagoda Box dashboard. It should look something like this:

Step 11: Cron Jobs (Optional)

A few recurring tasks in Magento (e.g. sending newsletters, log cleaning, customer notifications, etc.) need to happen periodically. The cron.php file located in Magento’s root will trigger these tasks. We’ll set up a Cron Job in the Pagoda Box admin panel to run cron.php every 15 minutes. (Note: To configure Magento specific tasks, see their Official Guide.)

Cron Jobs in the Boxfile

Cron Jobs can be added or updated via the Boxfile, then deployed to Pagoda Box. To schedule a task at 15 minute intervals, add the following to your Boxfile under the web1: component (change the “magento” to point to your own app name / subdomain):

  cron:
    - "*/15 * * * *": "curl -s -o /dev/null http://magento.pagodabox.com/cron.php"
    

Your updated Boxfile should look like this:

web1:
  name: mag-app
  shared_writable_dirs:
    - media
    - var
  php_version: 5.3.8
  php_extensions:
    - pdo_mysql
    - mysql
    - simplexml
    - mcrypt
    - hash
    - gd
    - dom
    - iconv
    - curl
    - soap
  after_build:
  - "mv pagoda/local.xml app/etc/local.xml"
cron:
    - "*/15 * * * *": "curl -s -o /dev/null http://magento.pagodabox.com/cron.php"
db1:
  name: mag-db
  type: mysql
  

Alternate: Cron Jobs in the Dashboard

In the Pagoda Box admin panel under the Cron tab, add the following (change the “magento” to point to your own app name):

Command: curl -s -o /dev/null http://magento.pagodabox.com/cron.php

Schedule: */15 * * * *

It should look like this:

Part 2 – Optimization: Redis, Scaling & Benchmarking

You’ve already gotten the heavy lifting out of the way. Your Magento application is scalable, and changes are easily deployed across all instances with $ git push pagoda --all.

In the follow-up article, we’ll optimize Magento, add a Redis cache, SSL and Domain aliases, then scale the application for benchmarking and production. See you soon!