Allison Wagner wrote a thoughtful post summarizing her experience with LESS on Happy Cog‘s lovely blog, Cognition. Her criticisms echoed my own when I first started using the self-described “dynamic stylesheet language,” so I thought I’d respond to them here so that other designer/developers might avoid similar points of trepidation.

She starts with the difficulty of debugging the compiled CSS:

LESS, by virtue of the compiler, rewrites and reformats CSS, which means the line numbers referenced by Web Inspector or Firebug are guaranteed to be wrong. I found myself having to search for styles a lot more, whereas in the past I would have simply referenced the line number in the debugger. While this may seem like a small annoyance to many, it slowed me down quite a bit.

Yep, totally annoying and, as Allison suggests, never 100% avoidable. While I would argue that fundamental LESS features (such as variable and operator support) more than make up for time lost to this quirk, there are still a couple of ways to minimize its impact:

1. Use @import in your primary style sheet to include your mixins and variables in one or more separate files. Since these will usually contain the majority of your un-compiled styles, the resultant CSS should map a little bit closer to your LESS line numbers.

2. If you’re using less.js for development (as opposed to less.app or a server-side compiler), calling less.watch() will tell the script to asynchronously recompile whenever your style sheet is modified. This can greatly expedite troubleshooting, especially if you have enough screen real estate to develop and preview side-by-side.

Allison’s other concern is the risk of “code bloat”:

Let’s face it, CSS is not exactly a champion of the DRY (Don’t Repeat Yourself) programming principal. Repetitious values in a pure CSS style sheet are the mark of a solid design system. Even the most well-written, pure CSS is typically teeming with identical declarations repeated over and over. I like that LESS advocates a very DRY approach to writing styles with shortcuts like mixins. And while the DRY approach is promoted inside the LESS files themselves, the generated CSS is anything but DRY. In fact, it’s far less DRY than pure CSS.

She provides a brief example of potential code bloat while suggesting that LESS users “are encouraged to embed [declarations] into each selector individually in the form of a mixin”. To be clear, this behavior isn’t encouraged by LESS any more than repetitious selections are encouraged by jQuery. If you use LESS to enhance your existing principles of well-formed and scalable CSS, there’s no reason why your code bloat should become unmanageable.

Example time! Let’s say we have an hCard with a photo, full name and role we’d like to style. Our vanilla CSS might look like this:

.vcard {
    border: 1px solid #ccc;
    margin: 10px;
    padding: 10px;
    -webkit-border-radius: 3px;
    -moz-border-radius: 3px;
    border-radius: 3px;
}
.vcard, .vcard .photo {
    -webkit-box-shadow: 0 1px 3px #eee;
    -moz-box-shadow: 0 1px 3px #eee;
    box-shadow: 0 1px 3px #eee;
}
.vcard .photo {
    float: right;
    margin: 0 0 10px 10px;
}
.vcard .fn {
    font-weight: bold;
    text-transform: uppercase;
}
.vcard .role {
    color: #999;
    font-size: 87.5%; /* 14px / 16px */
}

Not unmanageable. But let’s see how we can make it easier to read, write and expand upon using LESS. We’ll start by looking for things that can be re-used or streamlined. The gutter value seems to be consistent, so we’ll move that to a variable so we can change it easily. Also, those vendor prefixes are a bit lengthy, so we’ll move them into mixins we can re-use anywhere.

@gutter: 10px;
.border-radius (@radius) {
    -webkit-border-radius: @radius;
    -moz-border-radius: @radius;
    border-radius: @radius;
}
.box-shadow (@shadow) {
    -webkit-box-shadow: @shadow;
    -moz-box-shadow: @shadow;
    box-shadow: @shadow;
}

With our variables and mixins established, we can rewrite our LESS like so:

.vcard {
    border: 1px solid #ccc;
    margin: @gutter;
    padding: @gutter;
    .border-radius(3px);
    &, .photo {
        .box-shadow(0 1px 3px #eee);
    }
    .photo {
        float: right;
        margin: 0 0 @gutter @gutter;
    }
    .fn {
        font-weight: bold;
        text-transform: uppercase;
    }
    .role {
        color: #999;
        font-size: 14 / 16 * 100%;
    }
}

Note the use of the ampersand combinator, which will be replaced with the parent selector (.vcard) in the output. Combined with the nested .photo, .fn and .role selectors, we’ve avoided re-typing the parent selector altogether. We’re no longer repeating vendor prefixes or margin/padding sizes, and LESS can do the font-size math for us. Best of all, the output is identical to that of our vanilla CSS. Sayonara, code bloat!

I’m not saying that Allison’s criticism isn’t a possibility in LESS… only that it’s a direct result of how you choose to use the language. In his blog post CSS: Taking control of the cascade, Jason Z. illustrates a LESS technique that he finds valuable in spite of its verbosity. LESS won’t make these decisions for you, it only provides the tools to do the job faster and easier than you could have otherwise.

To quote Stan Lee in Spider-Man’s first appearance, “with great power there must also come — great responsibility!”

I am convinced that there will come a time when the web will take over and no one will be able to tell the difference between a web app and a native one but we’re not there yet. Today and for a few years, native apps will still provide a better experience.

I have a profound respect for designers who start from a purpose instead of a platform.

I was fascinated by Kill Screen’s interview with Tiny Wings creator Andreas Illiger, particularly how rejecting opportunities has allowed him to retain creative autonomy.

The Icon Handbook is clearly the essential resource on the subject, and not merely by default. Jon Hicks has done a wonderful job covering many aspects of icon design from history to theory to execution. Plus, it’s gorgeous! I can’t wait to receive the print edition.

Finally, IGN posted a wonderful “making of” video for Rayman Origins, one of my very favorite games of 2011 and arguably one of the best platforming games of all time.

I usually shy away from political issues here or on my public social media channels. If you’re reading this, you probably want to see posts on web design, games, comics and assorted geekery. Other nonsense would seem, well, nonsensical, so I choose to omit it.

I’m making an exception today because SOPA and PIPA threaten to irreparably damage the foundation of the web (DNS) in a futile and misguided attempt to curb piracy. New and innovative apps, websites and social networks could be crippled without sufficient process just to stop a handful of errant users from uploading copyrighted material.

If you’d like to protect this industry’s ability to innovate, please contact your representative and let them know that you disapprove of this legislation.

Here are some helpful resources:

• EFF: Stop the Internet Blacklist Legislation
• SOPA Strike
• A List Apart: Say No to SOPA
• The Verge: The SOPA Story So Far

Thank you for indulging this bout of activism. We now return to our regularly scheduled drawings of Rayman holding a Portal gun and Sonic the hedgehog running like an idiot.

Portal 2 (PS3/Steam) and Rayman Origins (PS3) continue to amaze me. Both titles, in completely different ways, aren’t just a blast to play… they teach me things about game design and design in general. They are engrossing, masterful works.

Some honorable mentions:

• Super Mario 3D Land (3DS)
• Pushmo (3DS)
• League of Evil (iOS)
• Tiny Wings (iOS)
• Sonic CD (iOS)
• Jetpack Joyride (iOS)

I also thought Sonic Generations (PS3/Steam) was fun, but mostly for the nostalgia. I haven’t had a chance to play Bastion (Steam), Q.U.B.E. (Steam), L.A. Noire (PS3) or Arkham City (PS3) yet, though I’d like to.

I don’t think it’s an accident that most of these titles are portable, with shorter play sessions. When I was in school, I could devote whole weekends to uncovering every unlockable in some sprawling epic. Today, every hour I spend playing games is an hour I’m not making games… or websites, or apps, or whatever.

As an adult, shorter games feel somewhat merciful.

Job titles are weird. Here are a few I’ve had (seniority omitted for brevity’s sake):

• Designer/Developer
• Graphic Designer
• Interaction Designer
• Visual Designer
• Experience Designer

All of these have separate Wikipedia articles. None of them rank in the 2010 ALA survey findings (unless you count “Other,” the third most popular option).

In college I majored in Interactive Media Design, which they used to call Multimedia & Web Design. After I graduated, they changed it to Web Design & Interactive Media before merging it back into Graphic Design.

Some of my favorite web designers are graphic designers. Some of my favorite game makers are also my favorite web and interface designers. It seems like half the designers I’ve ever known are musicians (the other half are, of course, photographers). One of them is an abstract painter and sculptor, and one just built a chicken coop.

Perhaps the web naturally attracts the oddballs and outsiders of adjacent industries. Or maybe it’s too young to accurately define itself.

Another possibility: This could be the first medium where making and publishing something is often quicker than explaining it. Sometimes we don’t even know what we’re doing until our users clue us in.

This time last year, Tim Sears and I released Ramps 1.0 to an unsuspecting public. A couple weeks later, Apple featured us as an iPhone Game of the Week. In May, we doubled the game’s content with the dark world update.

During that time, we received one request more than any other: iPad support. It took a while to do it right, but that request is now a reality.

Ramps 1.2 is universal, a free update for existing users, and available now!

Get Ramps in the iOS App Store

For more info, check out my post on the Backabit blog. Happy holidays!

So how’d it turn out?

The pitch

I’ve been a frequent user of Wacom tablets for years (at one time using a “Penabled” tablet PC as my primary laptop), so my quality bar for styluses is set pretty high… every capacitive stylus I’ve tried has failed to meet my expectations. Because of this, I ignored most of the initial Cosmonaut murmurings on Twitter.

Luckily, Calvin Ross Carl mentioned the campaign to me again, suggesting I at least watch the introductory video.

Despite my initial skepticism, I was impressed by the concept. Instead of attempting to circumnavigate the touchscreen’s limitations to deliver a compromised fine-tip writing tool, Studio Neat embraced the lack of precision, drawing inspiration from dry-erase markers and emphasizing the weight and feel of the object itself. I appreciated that thoughtfulness and forked over a paltry sum for the opportunity to try it firsthand.

The stylus

The Cosmonaut arrived in a stylish-yet-understated cardboard box, the soviet space theme lovingly maintained throughout the presentation. It made me smile.

The stylus itself feels very substantial in the hand. It’s a little heavier than a whiteboard marker, moreso as it comes to a point. I had to look up antonyms for “slippery” to describe its rubberized, outer coating, but “unslippery” is still the best description Thesaurus.com or I could come up with.

The pen tip feels firm and plastic to the touch, but it’s actually squishy and flexible. It’s tough to describe, but a brief tap with the tip of your finger will feel very resistant, whereas a firmer tap and hold will make it flex inward. It’s a surprising combination that makes the stylus feel sturdy and reliable without risking damage to the screen.

In use

I tried the Cosmonaut in my two favorite iPad sketching apps, Adobe Ideas for whiteboard-style doodling and Procreate for painting.

When sketching in Ideas, I found I had to press just a little more firmly than I would have with my finger, but once I learned to do this without trepidation, writing and doodling began to feel natural. While it didn’t feel quite like a dry-erase marker on a whiteboard in terms of effortlessness, I definitely felt my dexterity improve with the stylus.

This improvement was even more noticeable when painting. Procreate’s interface is so well-designed to begin with that, combined with the comfort of the Cosmonaut, I quickly forgot about either tool and just enjoyed the act of making a fun little Mickey Mouse sketch. For me, that’s the mark of a great design… the object disappears, allowing you to focus on the task itself.

The verdict

I feel a strange sense of pride in writing this review. While Studio Neat clearly deserves 99.9% of the credit for the Cosmonaut’s existence, it feels great to have been an early supporter.

This is easily my favorite capacitive stylus. By abandoning the goals of traditional, resistive touchscreen input devices and instead focusing on comfort and contextual appropriateness, they’ve successfully created a useful and charming tool that’s earned a spot on my desk (in the Gorillaz mug, next to my Wacom pen and my favorite mechanical pencil).

Now I just have to count the days until I get to watch Indie Game: The Movie…

I could not resist joining this meme, especially given my fondness for the blue guy.

In no particular order and with absolutely no feasibility research…

• Browser type previews (“Safari on OS X,” “IE8 on Windows 7,” etc.)
• Straightforward effects palette but with support for re-ordering and repeated effects
• CSS code snippets for effects (shadows, gradients, etc.)
• Vector objects with pixel snapping
• Smart objects but with optional file linking (with automatic updates)
• Integrated grid builder
• Object styles, library assets and interaction states (hover, active, focus, target, custom)
• Project files with support for multiple pages with multiple layouts
• Browser-viewable design previews with Recurse-style background image stretching
• Google Web Font previewing (maybe even Typekit with a paid account?)

What do you think? Are these pipe dreams?

Thanks Calvin, Erik and David for ideas and inspiration!

When I first saw Comixology‘s Guided View™ reading mode for mobile devices, I assumed it was solely a clever means of squishing traditional comics down to a smaller form factor without sacrificing readability. It wasn’t until I received a Kindle Fire that I realized it also counteracts mosaic confusion by negotiating the panel sequence for the viewer. Equivalent features exist in most iOS comics apps (Dark Horse Digital being a personal favorite of mine).

Amazon debuted their own guided reading mode shortly after the launch of the Fire through an exclusive partnership with DC Comics (which got Barnes & Noble pretty riled up), and it’s quite a bit different. I made a short comparison video to demonstrate:

While Comixology’s Guided View kills two birds with one stone, Kindle Panel View doesn’t alleviate mosaic confusion… in fact, it may exacerbate the problem. The Lightbox-style overlay introduces visual complexity, requiring the reader to parse three layers of depth: the focused panel, a gray overlay and the full page. Because the entire page is always visible and transitions are sparse, the mosaic demands a fresh analysis for each and every panel. I’ve never had to think so hard about the act of reading a comic book before.

The Fire is actually a pretty great device for reading comics on the go. My hope is that Amazon improves Kindle Panel View quickly, or that the DC exclusivity deal ends quickly enough to allow books like Watchmen and Dark Knight Returns to be effortlessly enjoyed via competing apps.