Design, development & other matters
A lot of people have seen The Hobbit at both 24 frames per second (fps) — standard cinema frame rate — and 48fps — so-called high frame rate or HFR. Disclaimer: I have seen neither.
Many of the viewers, possibly the majority, who saw both and compared the two preferred the 24fps version to HFR. Their main argument declares that HFR exposes the artifice and over-compensation of set- and character-dressing in movie production.
Or to phrase it more simply: the "magic" of cinema is lost at more realistic framerates.
But there has also been a vocal minority likening the transition from 24fps to HFR movies to what happened with audio media formats. The main assumption here is that we'll just get used to and eventually demand the more perfect, more lifelike media. After all, imperfect analog vinyl gave way to the pristine, digital compact disc.
This argument conflates the media with the message. We chose CDs over vinyl — and now MP3s over CDs — because songs got smaller and easier to take with us while the audio quality stayed enjoyable enough to blast through our car speakers. Portability won the audio format war.
Meanwhile, most pop songs are still about love and relationships.
It doesn't take more than a flick through Instagram to see that even with our digitally perfect pocket-sized means of media production, we prefer to tell each other stories through crops and filters that render the final image more imperfect than its source material.
While all media formats will forever gain more definition, more bits, we'll continue to shape our messages with unique characteristics and embrace imperfections (even the artificailly-generated ones) in order to make the story more compelling to our friends or followers.
Is The Hobbit a bad movie for being shot and presented in HFR? No, but more importantly it's not a better experience simply on technological merit alone.
Any Compass-based project I've worked on had a config.rb where you set your Compass options (or in the case of Rails, config/compass.rb). In a new, bare-bones Yeoman project however, there's no such file. Instead, Yeoman uses Grunt to set the options for the Compass compiler.
The default settings for Compass looks like this:
compass: {
dist: {
options: {
css_dir: 'temp/styles',
sass_dir: 'app/styles',
images_dir: 'app/images',
javascripts_dir: 'temp/scripts',
force: true
}
}
},
Those options should look familiar: they're the same options used to configure Compass projects the world over.
The option require is what we're looking for in this case. Simply add it like so:
compass: {
dist: {
options: {
require: 'susy',
css_dir: 'temp/styles',
sass_dir: 'app/styles',
images_dir: 'app/images',
javascripts_dir: 'temp/scripts',
force: true
}
}
},
Now you can successfuly @import susy into your SASS files.
One framework is good enough for me right now, but I'm sure other people want more than one. As of now, you're out of luck.
I installed the Fancy Buttons gem and tried:
require: 'susy fancy-buttons',require: ['susy','fancy-buttons'],…and neither seem to work. You can't duplicate on object literals in Grunt so this doesn't work either:
require: 'susy',
require: 'fancy-buttons',
I have no idea how to include multiple frameworks as of right now, and would love it if someone could provide a solution.
UPDATE 2012-09-14 17:38:17: I figured out a decent approach: create a compass config file as you would for any other project, then tell Grunt where to get it with the config property. This means completely stripping most of the default options to this:
compass: {
dist: {
options: {
config: '.compass.rb', // I made it hidden because other Yeoman configs are hidden, too.
force: true
}
}
},
Your config file should use the settings Yeoman previously provided:
# Require any additional compass plugins here.
require 'fancy-buttons'
require 'susy'
# Set this to the root of your project when deployed:
http_path = "/"
css_dir = "temp/styles"
sass_dir = "app/styles"
images_dir = "app/images"
javascripts_dir = "app/scripts/vendor"
This isn't a hack or really that clever. Gruntfile.js is merely providing settings to pass along to the Compass compiler when Yeoman wants to run it. One of the flags for the compass command is --config, after which you specify what config file you want to use.
Notice that I changed javascripts_dir from tmp/scripts to app/scripts/vendor. I believe this is a better setting since javascripts_dir is mainly used for one-off framework installs like this. I already filed a bug about it.
Some frameworks will require an installation step to copy over assets into your project. compass install fancy-buttons myProject -r fancy-buttons, for example, will copy over button_bg.png to your images directory.
To install these assets into your Yeoman project, you must run the compass install command but also specify the location of the css, sass, image, and javascript directories so they align with Yeoman's conventions.
No big deal. You only need to do this once:
compass install fancy-buttons . -r fancy-buttons --sass-dir 'app/styles' --css-dir 'temp/styles' --images-dir 'app/images' --javascripts-dir 'app/scripts/vendor'
And away we go.
I just created a couple handy TextExpander snippets for scriptogr.am, the Dropbox & flat-file based blogging platform I moved to last week. You can download it from the GitHub repository… here.
I there's a lot to love about scriptogr.am. I'll spare you the details for now, but my main reason for switching was that I could write and publish from anywhere without going into a terminal, which is a drawback to Jekyll and similar no-DB content management solutions. So far, so good.
These snippets speed up the process of creating content files and loading the front matter required by all posts. They could totally be used for similar Markdown-based systems, but there's a few scriptogr.am-only snippets for the front matter.
I'd love to refine this further, so currently accepting pull requests!
AirPlay is a funny feature. It's not the easiest thing to discover, but pushing that first YouTube video from your phone to the living room's Apple TV is magical. It's hard not to AirPlay all the things from that moment on.
AirPlay was initially released as AirTunes back in 2010, designed just for audio streaming from iTunes. In less than two years, it now supports audio, image or video streaming from iOS to Apple TV and, soon, OS X.
Any iOS app can inherently send their media to AirPlay. Impressively, The Smithsonian Channel app lets you beam video to the Apple TV while exploring additional related content on the device. The experience is an entirely immersive and an innovative multimedia experience for the living room. It's the kind of technology usually reserved for cutting edge museums or galleries.
As iPhones and iPads gain muscle on the hardware front, AirPlay is maturing to support the ultimate in computer-based multimedia experiences: video games.
A few titles on the market today can do some pretty nifty tricks with AirPlay. Real Racing 2 has an AirPlay mode where the iPad becomes the controller while the action gets displayed entirely on the Apple TV.
Anecdotally, a friend of mine says it works great off an iPad 2 — with maybe a 1/4-second lag.
Oh…
Spend some time AirPlaying different types of media and that lag becomes noticeable. Try mirroring a game from a cutting-edge iOS device like the New iPad and enjoy sluggish framerates and crumbling controls. For video games that demand precise timing, anything other than immediate feedback is unacceptable.
That lag is inherently a part of our Wi-Fi signals. Should AirPlay become a bigger consumer draw than it currently is, Apple will undoubtedly figure out some way to make it negligable.
But there are plenty of game genres where even a second of lag doesn't matter: puzzles, quizes, trivia, card games and board games. Basically, party games for the casual gamer. Pass the device around to let players act while the TV shows the room the current state of play, scores, and other "public" information.
It doesn't take more than a few moments of thought to figure out how some of the most popular games for groups of all ages could be played on Apple TV with current devices:
(UPDATE: Matt Braun 1) informed me that Pictionary came out in '85 and 2) brought this idea to life with SketchParty TV!)
And these are just a few really quick thoughts. There are entirely new party game dynamics that result from having a fixed, large public screen and a portabe, personal second screen.
I am not an iOS developer, but I do read way too much on iOS development for someone who does front-end web development all day. If there are any limitations in the way, my assumptions are the following:
Maybe the introduction of AirPlay to OS X and the upcoming iOS 6 builds out the AirPlay API enough to make developing AirPlay-enabled games easier for developers.
A group viewing one screen with an individual manipulating another is definitely enough of a platform to build on, but of course its still not a true gaming platform. Might it be close enough though?
There is some serious Wii-like potential energy stored up here for some kick ass gaming experiences on iOS with AirPlay, and I feel that, just like the Wii, casual, group-based games could help bring AirPlay to a broader audience.
If you write code for a living, you probably follow fellow code-writers (on your favorite following service of choice) and read what they have to say about the new shiny they are currently working on. You probably follow them because they often write about their new shinys. Their new shinys are usually really shiny, and when they release a demo of shiny it's really freakin' cool.
You probably wish you were coding something new and shiny too. So you read some tutorials and give the shiny a try. But the shiny is just so new and fragile and intricate that you quickly get to a point where you can't do anything more with it: too confusing, kind of broken. Since you can't do anything with the new shiny anyway — it sure as hell isn't going into your produciton environment anytime soon — you put it away.
But other coder people on your follow lister-magigger start playing with the shiny too. Maybe enough people polish up the shine that it's now showing up on blog posts and at conferences and the like. Pretty soon people start saying that the new shiny is really the New Way, and probably soon the Only Way.
Or at least it seems like it.
So you pick up the shiny shiny again, which is really much more brillant than it was when you first played with it. Maybe you can do more with it this time. Maybe you get lost in the super shininess of it for a whole evening.
But then you go back to working on a project with your non-shinies. Maybe it's a big big project and now you can't find the time to get to the shiny again.
Then a year or so goes by. In that year you've worked on some projects that were challenging, rewarding, frustrating and exciting, but never with the shiny.
You tried to bring up the shiny on one of your projects, but your teammates decided it wasn't a good fit.
At this time the shiny has gotten really popular. All the cool kids use the shiny. Everyone else wants to be using the shiny. There are jobs listings in San Francisco for people that can use the shiny.
San. Fran. Cisco.
At this point, you're obviously falling behind in your industry of code people because you're not well-versed in the shiny. You start to get anxious about your job. You start to figure out what meatspace events you can skip so you can, finally, spend time getting up to speed with the shiny shiny.
At this point, a lot of what you do just feels like it really really could and really really should be done with the shiny.
At this point, every hour spent coding how you're coding and not coding in the new shiny way is an hour wasted.
I find it really tempting to fixate on whatever impressive new bleeding edge thing shows up at the top of a feed. I know plenty of other coders do too. That's because we shape the news we're interested in. We post, upvote, and RT the same shit about the same new thang at the same time during the same lull we have in the same project we've been working on for the last few months.
I don't think I'm exaggerating when I imply that many of us seem to hold passionate interest in something for a few mere months before something shiny comes along that seems that much better. Even when we're getting paid for that passion.
Look, that year that just went by where you managed to successfully do a job where you type all day and make something that makes other peoples' lives better is no minor accomplishment. It's a fucking successful thing that you did and it is time to be proud of it.
You also haven't mastered the tools you do every day and you know them a heck of a lot better than you do the new shiny ones, so why not try to refine something you've got a decent footing with rather than start all over with something new for the sake of its newness?
This post is a reflection on a recent post on Twitter's engineering blog about moving some of the client-side UI rendering back to the server, away from Javascript.
Funny enough, I recently burned some cycles experimenting with Backbone, Spine and Ember and decided I couldn't find any of them useful for me right now. Javascript MVC is the shiny of the moment for me. I felt defeated that I wasn't going the extra distance to master one of these tools.
Again, NO use for any of them right now, still felt like I should be using one of them.
But straight jQuery is doing me a world of good. It's a tool I'm very familiar with, but can't even begin to give a decent explanation on how it works. It's not shiny anymore, but it works amazingly well, and I need to feel better about the work I do with it.
When Blog Better Boston asked me what I was going to speak about, I said "design hacks" off the top of my head.
As the day approached and I thought more about my audience, I realized that the room would be filled with bloggers of varying degrees of technical proficiency. Something more general was in order.
The presentation wound up being something of a primer on typography & CSS. I wanted to get bloggers to understand any attempts at a redesign should start with the content, and the essence of written content is typography.
Since its relatively easy to play with type in CSS (most bloggging platforms have a user-editable "custom styles" field), I gave a quick overview of what CSS is and how to start experimenting.
We unfortunately started a little late and I hit my time limit before getting too deep into the CSS fun, but I got a couple great reactions from my first real workshop.
My slides really just supported my narration, so they don't stand on their own well. Nonetheless, here they are:
So Apple updated the iPad the other day?
Yes.
Retina display? Faster? Better camera?
Yep.
The last one was the iPad 2 right?
Yes.
Do you know what they called the new one? The iPad 3? The iPad HD?
The New iPad.
Right.
Yeah. What's it called?
The New iPad.
That's what I want to know! What's the name of it?
What do you mean? The name of the new iPad?
Right. What did Apple name the new iPad?
The New iPad.
Yes. The one they just announced. What'd they call it?
The New iPad.
The new iPad that they just announced.
The New iPad. Yes.
They named it the iPad Yes?
What?
I recently read Lazy as a Turtle's post Are you ready for the next stage of commoditization of web design?
The author summarizes that we've already gone through one phase of design commoditization of web design: sites like ThemeForest can sell respectabile site designs at very low rates, relegating the web designer to a mere theme tweaker.
The author then hypothesizes that the rise of Twitter Bootstrap and similar open source CSS frameworks "remove[s] the urgency for a bespoke design for start ups" and even advises "If I were making my living from web design, I would be looking into new pastures."
I can't help but feel that that last quote has more gravity than the author truly intended, but it sounds scary nonetheless.
No. Or maybe.
Start-ups may not need a dedicated designer, but they need design. They don't need pixel-perfect design though, and most web designers need to move on from pushing pixels anyway.
There are tougher issues for web designers to concern themselves with. So I thought I'd share my perspective in the article's comment field:
[Commoditization of web design] is a good thing for web designers. It's time to move on from just making pretty pictures of websites.
Making something look good enough for 80% of the web has been easy ever since CSS was widely supported. We as designers got caught up tweaking button sizes and gradients because, well, I don't know why.
Most content on the web is text, and the rules for good-looking text have been perfected for the centuries following the printing press: legible font sizes, proportionate paragraph lengths and line-heights.
It shouldn't take much of a designer's time to make good-looking text. Maybe you won't break new ground but you should be able to make it look beautiful enough for your client or project and move on.
As for the other components of a web page — navigation, layout, branding — if there's a theme out there that has most of that code written and supports the browsers you need, get it on-brand and move on.
There's more important tasks for web designers to do.
We need to focus on how sites work, what they say and how they make the users feel. Optimizing a sign-up or checkout flow is more important than getting the gradient on the toolbar just right. Figuring out what call to action copy speaks to your users is more important than the button being the perfect shade of red. Surprising and delighting the user is harder than cropping a stock photo of a multi-ethnic group of children.
These qualities of a site are the true challenge of web design and the challenge varies from project to project. SOMEONE needs to manage the process, communicate, iterate over ideas and experiment on production regularly. The start-up might not need a web designer, but they need to go through the motions of a good one.
I don't think these are the "new pastures" the author mentions. Rather, its shifting the emphasis of the production process from the part that's easy, making a site look good in a browser, to the part that's hardest for everyone: figuring out what to say and how to say it as simply as possible.
Basically: getting a site to work effectively is a lot harder than getting it look good. There is plenty of value here. That value may come from an in-house designer or simply people on the team willing to play the part. But it has to happen some way or another.
All start-ups need someone on the team using the product or service, to put it in front of users and see if what the team has built actually works or if they need to take it back to the drafting table.
That's true design, in the Mike Monteiro sense, right there. You can't commoditize that process.
So I was a little skeptical of the comment field of Lazy as a Turtle. I'm not sure why. So just in case, I copied that comment to the clipboard before I submitted. Then this happened:
The site is broken, plain and simple.
Someone needs to get a designer on that.