Eric D. Fields

Design, development & other matters

Jan 27, 2014
Exposing iTunes Radio's Silly, Silly Album Art Stacks

WARNING: Once seen, this can't be unseen.

Question: how do you turn one piece of album art into six unique images?

"iTunes Radio Album Art"

Answer: Zoom! Enhance! Rotate!

I assume the original design demonstrated iTunes Radio stations represented by a stack of album art taken from random albums whose tracks could be found in the station. "Oh, and they do this cool thing when you horizontally scroll them…"

If that was the original intent, who knows why it doesn't work like that in reality. But chopping and screwing the album art as a cheap alternative is just a lazy excuse to keep a neat-o special effect.

Jun 23, 2013
Moving a blog from TypePad to Squarespace is painless if you follow these thirteen simple but very detailed steps. You'll regreat nothing.

"Never has there ever been — nor will there ever will be — a transition between two content management systems wherein the result is 100% content preservation, naught but admiration for the new system, and a pleasurable, stress-free experience." — Socrates, probably

As of this writing, we've sucecssfully moved The Good Girl Gone Blog (G3B) from TypePad to Squarespace. The reasons for doing so were many:

  1. TypePad.
  2. I mean, c'mon!

In the last decade, CMS UI and the needs and expectations of how people use CMS's has evolved. Yet the TypePad of 2013 is pretty much the TypePad of 2003. "Hey, man… we've got stylesheets!"*

Squarespace, on the other hand, is the cat's banana, which is to say it is one of the more refined, focused, and usable content management systems out there. It was designed in and for the modern Internet era. Once-excotic blog includables like video and image galleries and Amazon affiliate links are now commonplace.

Their templates are effortlessly responsive and customizable, and now that they've unlocked Squarespace for Developers, shit just got so so real. I mean you try updating your Blogger theme by committing to GitHub. I'll wait.

Ready?

Now this wasn't the hardest process, but it wasn't the easiest either. It involved some planning and knowhow. I spent the first few hours figuring out the known knowns:

  • TypePad hosted all the images with URLs based on the domain name. If the domain pointed at another service, images would break.
  • If we stop paying TypePad (by going to another service), there's no reason to believe images would stay hosted even if they were at a more permanent URL.
  • Squarespace 6 will import content from a number of popular blogging platforms, but TypePad is not one of them.
  • Squarespace 6 will import WordPress, and WordPress will import a TypePad export.
  • All linked TypePad images have to be sucked down and moved somewhere else in perpitutiy.
  • Post slugs will change. Image slugs will change.

Set?

It's really not that bad. It's just many steps that have to be done in the right order. Note I'm ignoring anything around the actual design of the blog and preserving things like the template markup. I'm assuming one of the reasons you're moving to Squarespace is to shake up your look and feel.

Go!

  1. Export your blog from TypePad. You'll get a flat text file. At this point, you are done blogging on TypePad. Don't write any more posts there while this process is underway.
  2. Get a list of all your images hosted on TypePad Huge high five here to Martin Sauter who came up with a great python script to parse that file you just downloaded for all image links. Here's the post. Here's the script (posted on GitHub without permission but with attribution).
    1. Once you have the script, you're going to run it like so: './get_links.py blog.txt domainname >> image-urls.txt'
    2. We had at least three different domain patterns for our images
      • www.thegoodgirlgoneblog.com
      • thegoodgirlgoneblog.com
      • goodgirlgoneblog.typepad.com
    3. Do step 1 for each domain. The >> will append the results so you'll wind up w/ one awesomely huge file of image links.
  3. Download all your images from TypePad. wget -x -i image-urls.txt That -i flag is super crucial. That saves the directory structure of the original image. You want this for the sake of matching the old images to the new ones. TypePad uses hidden directories (.dirname) so watch out for those…
  4. Upload all your images to S3. S3 is cheap and forever (OK so long as you keep paying them, but it's super cheap). I used Transmit for this. Make a bucket like mysite and a folder named archive. Upload the top-level folders you got out of the last step to archive. However you chose to upload to S3, make sure it's setting the headers to Content-Type image/jpeg. TypePad was kind enough to not append a file extension to most of the images, so you have to tell it. In Transmit, this can be done in preferences. Just update the default for now.
  5. Make all your S3 images world-readable.
  6. Find and replace old image URLs with new image URLs. You'll be looking for patterns like http://goodgirlgoneblog.typepad.com/.a/filename and replacing it with http://thegoodgirlgoneblog.s3.amazonaws.com/archive/goodgirlgoneblog.typepad.com/.a/filename. This right here is why you wanted those top-level dirs.
  7. Triple-check everything. You probably missed something.
  8. Import your content to WordPress. If you have a multi-megabyte text file, the free WordPress.com blogs will probably choke on it and not import things properly. Get WordPress running locally. Use its Import TypePad plugin. Hopefully you don't have multi-author problems to worry about, but even if you do it shouldn't be too difficult to deal with here…
  9. Update your slugs to match what you had on TypePad. Do this before you export back out to WordPress XML. You can also chose not to make them exactly what you had before, but there best be some rhyme to your reason, and you really do have to end the post with a slugified string (like-this-kind-of-thing).
  10. Export to WordPress XML. Grab a beer.
  11. OK NOW IMPORT TO SQUARESPACE!!! Sober up. Next comes URL Mappings.
  12. Set up your URL Mappings. This is a very important step that will help you from losing any acquired Google juice.
    1. In Squarespace, go to Settings > Advanced.
    2. We're basically telling squarespace "post URLs used to look like this, so if you see one of these come here, go to a different URL instead."
    3. I decided posts would live at /posts and I knew we were merging a few categories, so I wound up with something like this:
  13. Enable your blog. In the Squarespace Content Manager, you should see your imported blog as a new collection. Click its gear and update the url to whatever you decided on (/posts in our case) and you probably want it to be the home page. Enable it.
  14. Update your DNS Records. You've got an A Record and a CNAME to set then it's all money.

YOU JUST LEVELED UP!

That, my friends, is exhaustively all there is to it. I probably missed something. Please give a shout if something isn't clear and I'll update it.

Jan 26, 2013
Assuming HFR is the future of movies just because most people don't listen to vinyl anymore confuses media technology with good story-telling.

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.

Sep 14, 2012
Yeoman uses a Grunt.js file for its settings, so installing Compass frameworks is a little bit different…

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.

How Yeoman Sets Compass Options

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.

Our Solution

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.

Caveats

Requiring Multiple Frameworks

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.


Installing Framework Assets

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.

Sep 4, 2012
I got into branch and needed something to discuss. I'd love to get input from other scriptogr.am users, so please request to join in.
Sep 4, 2012
Handy TextExpander snippets for generating and marking up content for scriptogr.am.

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!

Jun 20, 2012

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.

What can AirPlay do today?

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.

AirPlay as a gaming platform

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…

About that lag…

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.

Casual gamers aren't in such a rush

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:

  1. Scrabble. Scrabble for iOS was one of the first noteworthy games that allowed players to use mulitple iOS devices to play one game. Famously, it lets an iPad act as the board while each player uses their iPhones and iPod Touches to organize their tiles. Whatnot use AirPlay to let the TV show the board at all times. Players can use their own iOS devices or pass just one around to manage and place tiles.
  2. Settlers of Catan. My girlfriend and I have played games of Catan on the iPad dozens of times (though now she prefers to just play against computers because "its faster"). Because your resource cards must be kept secret, and you must be able to see the board to make a move, only the current player can see the board at any given time. Unlike the physical board game, this limitation means players cannot easily monitor the unfolding action or strategize while the others make their moves. Leave the board and score data on the TV at all times and you get a closer analog to the tabletop game.
  3. Pictionary. Pictionary is the Draw Something of the 70s 80s. With the iPad canvas in hand being reflected on AirPlay, the artist may draw on the tablet while her teammates guess the form. Sketch history could be reviewed on the screen for laughs after the game is over, or emailed to the group for posterity's sake.

(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.

AirPlay's hurdles as a game console

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:

  1. Fragmentation of HDTV resolutions. Apple TV requires an HDMI input, which pretty much guarantees at least 720p as the baseline television. Ideally, that means a resolution of 1280 x 720 pixels. I've seen 720p resolutions referencing at 1024 x 768 pixels. And of course 1080p's resolution is 1920×1080. Or not. Our biggest lesson from Android is that designing beautiful pixels for multiple screen sizes is hard. However, console game developers have been doing this since games went HD, so there should be plenty of knowledge available.
  2. AirPlay is under-developed or under-documented as an API. Real Racing and The Smithsonian Channel are stellar examples of apps developed for the two-screen experience, but the lack of many others makes me think that there's something about the AirPlay API that makes this difficult right now. Sky Battles is another title that should make innovative use of AirPlay, but we'll have to wait a bit longer to see how. Maybe all of these developers got special help from Apple. Maybe they're just really, really, ridiculously good.
  3. Anonymous iOS devices have a hard time talking to each other. This isn't a true blocker, but while one AirPlay-enabled iOS device should be enough to make a fun party game experience, many would multiply the gaming possibilities. If you've ever tried linking an iPhone or iPod Touch to Scrabble on the iPad, the current state of affairs is painful.

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.

AirPlay alone does not a game console make

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.

May 29, 2012

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.

Stop it, please

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.

Mar 26, 2012

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:

Mar 8, 2012

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?