capcloud | Martin Polley

Setting up a Static Blog on OS X to Publish to S3 [UPDATED]

WARNING: This is rather a technical post. If you’re not comfortable doing neckbeardy things like typing stuff at the Unix command line and adding stuff to your bash profile, you probably want to give it a miss.

All I wanted to be able to do was write posts in Markdown in a Dropbox folder and have them be automatically published as a static blog hosted on Amazon S3. On a Mac. Not too much to ask, right?

Well it turned out to be quite difficult and time consuming, with lots of wrong turns into blind alleys. So if you’re thinking about setting up something similar, here’s what worked for me.

The Pieces

This setup only really has two pieces:

• A static blog generator—this takes files that you write (typically in Markdown) and converts them into a set of HTML pages, including a main page, individual post pages, archives, etc.

• Some way to sync these HTML files to S3.

And this is what I actually ended up using:

• Pelican

• s3cmd

I also used Lingon to automate it all (using launchd).

But first a little bit on how I arrived at this point.

Some Right Turns, Some Wrong Turns

There are many static blog generators out there. The most popular seems to be Jekyll, so I decided to have a go at installing that. It uses Ruby. Macs come with Ruby, so it should be easy. It went OK, but eventually I reached the point where I was required to upgrade Xcode. Xcode is a hefty download, and I didn’t want to wait, so I started looking at alternatives.

Pelican seems to offer similar functionality to Jekyll, but uses Python instead of Ruby. And Python is also pre-installed on OS X, so why not give it a shot? So I installed Pelican and the things that it requires: pip, virtualenv, and virtualenvwrapper. (Ignore the fact that the pip docs say you can get pip by installing virtualenv—the easiest way is to install pip and then use it to install virtualenv.) Pip also requires another package called distribute, so install that too. And if you want to write in Markdown, you’ll need to install the Markdown module, as described in the Pelican docs.

So now that I’ve got all these installed, it should “just work”, right? You wish. To get Pelican to generate the HTML, you need to run the make command with the makefile that comes with Pelican. But to get make (if you don’t already have it), you need to install the latest version of Xcode. (Déjà-vu much?)

So, much later that day, I have the latest Xcode, and have installed the optional (but required here) command-line tools. Now it works, right? Well, almost. Now I get an “unknown locale” error. Say what now? A little more Googling reveals that I need to set the LC_CTYPE environment variable in my .bashrc file to something like en_US.UTF-8. (An aside: I tried all this with tcsh, which I like more than bash, but ran into even more problems, so I switched back to bash.)

Anyway, now, finally, it works. On to the next piece of the puzzle—syncing the files to S3.

There were a couple of things that I tried that did not work for me. The first was trying to mount my S3 bucket as a remote drive using MacFusion. I thought I could mount the bucket right inside a folder in my Dropbox. But it didn’t really work.

The second was trying to upload using SFTP via an FTP-to-S3 gateway (like Cloud Gates). The gateway part works great (and I use it regularly for other stuff). And Pelican has an FTP make target that you can modify to use SFTP. But again, it didn’t really work.

s3cmd, on the other hand, works great. At least, once I figured out that I needed to install the latest version from Github instead of the one on the download page. s3cmd has a sync command that lets you sync a local directory with one in your S3 bucket.

Automating It All

The only thing left to do was to automate it so that as soon as I add or change a file in Pelican’s content directory, it will automatically regenerate the HTML and sync the output directory with S3.

On OS X, launchd is the thing to use. But manually creating the necessary plist files is a bit of a pain. Thankfully, there are tools that can make it easier. One of these is Lingon. I used it to add two items:

• One to start Pelican’s make regenerate, which, once started, detects any changes in files in the content directory and updates the HTML

• One to run s3cmd sync whenever the index.html file in the output directory changes

This is what they look like in Lingon:

I couldn’t get these to work by typing the commands directly into Lingon—I had to wrap each one in a shell script. This is what they look like. (Of course, you’ll have to change the directory paths and the S3 bucket name.)

To run make regenerate:

#!/bin/bash

source /usr/local/bin/virtualenvwrapper.sh
cd /Users/martinpolley/Dropbox/konigi/protokit/projects/blog
workon pelican
make regenerate

To sync with S3:

#!/bin/bash

/usr/local/bin/s3cmd sync --delete-removed \
/Users/martinpolley/Dropbox/konigi/protokit/projects/blog/output/ \
s3://livetyping.capcloud.com/blog/

Don’t forget to chmod +x these so they can be executed.

Some Other Gotchas

When you’re writing posts, you must give them a title and a date, like this:

Title: My Awesome Post
Date: 2013-03-31

If you don’t, Pelican won’t process them. You can also add a status of “draft”:

Status: draft

Pelican will put the generated draft post in a folder called drafts. The post will not appear on your blog until you remove this line.

Conclusion

This was a total pain in the ass to set up. But the result is so worth it. When I hit save in Textmate, and twenty or so seconds later, the post appears on my blog, it feels like magic. And because the files are in Dropbox, I can do the same in iA Writer on my iPhone or iPad (or move from one device to the other if the kids are playing Subway Surf on the iPad).

You can see it in action on the Livetyping blog.

UPDATE: After finding that my whole blog had completely disappeared (twice), I stopped using --delete-unused in s3cmd sync…

Breaking up the Band

OK, well, not really. I’m actually splitting this blog up into two blogs. Stuff related to UX (and especially HTML prototyping) will be posted on the Livetyping blog, while everything else will be posted here.

Right now, the only thing on the Livetyping blog is my recent post about front-end frameworks, which I copied across from here. In the coming days, I’ll be copying other relevant posts over too, so they’re in the “right” place.

So if you follow me for the UX stuff, you should add this RSS feed to your feed reader.

The Best Framework for UX Prototyping in HTML

While I was putting together Livetyping (my online course that teaches UX designers how to create prototypes in HTML, CSS, and Javascript), I used Foundation for the prototype that I showed how to build. But Foundation isn’t the only front-end framework out there. So I decided to take a look at a couple of others to see how they compare. Enjoy.

If you’re prototyping in HTML, CSS, and Javascript (or just thinking about it), you probably already know that using a framework can save you a lot of time, especially if your design needs to be responsive. (And these days, with a few exceptions, there aren’t many reasons to make a design non-responsive.)

But how can you know which one is best, without downloading them all and trying them for yourself? This post aims to save you the hassle by explaining the pros and cons of each from a UX prototyping perspective.

The Contenders

The two most popular frameworks are Bootstrap, originally created at Twitter, and Foundation, created by product design company ZURB. There is also a dark horse candidate called Skeleton, which was created by Twitter designer and former ZURBian Dave Gamache.

What Are These Things, Actually?

All three of these frameworks let you lay out web pages on a responsive grid. This means that you can make your design work well on any screen size. If that’s all you need, Skeleton fits the bill. (Bootstrap and Foundation also do this, but they bundle in a lot of extra stuff too.)

But for all but the simplest prototypes, you will almost certainly need more than just layout. The questions you need to be asking are What do we need? and What do we know?

If you need things like tabs, nicely-styled buttons and forms, standardized navigation components, consistent typography, and so on, then both Foundation and Bootstrap come with stuff that makes adding these things easy and fast (and they will look consistent too).

If you know how to do these things yourself (and want to), Skeleton could be the answer.

How they Look Out-of-the-Box

Skeleton

Skeleton on the Desktop

Skeleton on iPhone

Bootstrap

Bootstrap on the Desktop

Bootstrap on iPhone

Foundation

Foundation on the Desktop

Foundation on iPhone

What You Get in the Box

Skeleton

Skeleton gives you a responsive grid, some basic typography, and some simple form and button styling. That’s it.

Bootstrap and Foundation

In terms of feature lists, there is a lot of overlap between Foundation and Bootstrap. I won’t list them all out here because others have already done a better job than I would (scroll down to UI and Widgets at the bottom of the page).

In short, they both provide a responsive grid, nice typography, improved form styling, and pretty much any UI component that you might see in a modern webapp. So instead of listing them out here, I’m going to point out some of the differences between the two:

• Bootstrap comes with a set of 140 (naturally) icons. Foundation does not include icons, but ZURB have created several icon fonts and a set of social icons (as separate products) that you can use.

• Foundation has iOS-style switches, which are a nice alternative to checkboxes.

• Both Bootstrap and Foundation have visibility classes, which let you show and hide elements depending on the screen size. Foundation goes one step further by adding visibility classes for device orientation and touch support.

  This means you can do things like:

  • Replicate the pattern seen in many iPad apps, where a sidebar is displayed in landscape mode and hidden in portrait.

  • Show affordances on touch devices that usually only appear on hover.

• Bootstrap seems to offer more built-in options for styling tables.

• Bootstrap includes iPad-style popovers.

• Bootstrap comes with animated transitions for fade in/out and slide in/out.

• Both Foundation and Bootstrap have wizards that let you customize their framework before you download it. Bootstrap seems to have more things you can customize, which may or may not be a good thing.

• Foundation has 13 templates for common page layouts that you can download from their site. Bootstrap comes with eight example pages included in the download.

But maybe the most important difference between the two frameworks is that Bootstrap is much more style-heavy than Foundation. This means that you see lots of sites that are very recognizably built using Bootstrap. For prototyping this may not matter so much. After all, what we are prototyping is not the visual design, it’s the layout and functionality. But on the other hand, if the way things look by default draws too much attention to itself, that may be a disadvantage.

As someone cleverly put it in an answer to a Quora question about this:

> It is like the difference between buying a custom Lego kit or buying a bunch of Legos on eBay and then trying to build something from the kits that you scrapped together.

Other Factors

Up-to-date-ness

Foundation and Bootstrap are both being actively developed, and new versions are released frequently. Skeleton, on the other hand, has not been updated in months. But since what it does is relatively simple, and because it is not engaged in a feature war with the other two (just the opposite, in fact), this may not matter in the slightest.

Popularity

Now, you don’t want to be a sheep and just go with the one that everyone else is using. But popularity does matter. It matters because Bootstrap is attracting people to develop other products that are based on it. And some of those could be quite useful to us.

Protostrap lets you put prototypes together more quickly by using PHP to reuse content. It also includes some enhancements to Bootstrap, including a fake authentication layer, a way to handle missing pages gracefully, an iOS tab bar, a carousel with touch support, more icons, and more.

Jetstrap is webapp that lets you lay out Bootstrap pages visually, without having to write any code.

There does not seem to be anything similar for Foundation yet.

Under the Hood: Less and Sass

Both Foundation and Bootstrap let you work in plain ol’ CSS. But they both use a CSS preprocessor that lets you do more powerful things (and keep your code simpler). Bootstrap uses Less, while Foundation uses Sass. If you know what these are and have a preference, this may sway your decision.

Documentation

Another important factor is how easy it is to learn each framework. For this, you’ll be relying on the provided documentation.

Skeleton’s documentation is understandably sparse. There’s not a lot to explain here, but the docs do a perfectly acceptable job of explaining it.

Foundation and Bootstrap both have very good documentation, but I think Bootstrap has a slight edge here.

Conclusions

Is any one of these head-and-shoulders above the others, a clear winner? No. All three frameworks are very competent.

So which one should you use? The answer is a typical, designerly “It depends”.

Each one just has a different emphasis, so which one is right for you depends on what you’re trying to do.

Do you mind all your prototypes having a similar look and feel? Maybe that’s even a positive in your eyes. If so, Bootstrap is a strong contender.

Do you prefer to impose your own look and feel on your prototypes (not necessarily a proper visual design that approximates a finished product, but maybe one that looks more wireframe-y)? Foundation could be the one for you.

Do you have strong CSS and Javascript skills and want complete control over both the way your prototype looks and how it behaves? Then check out Skeleton.

“But which one do you use?” you ask. Well, I use Foundation. Why? Because I started using it before I’d even really heard about Bootstrap or Skeleton or had a chance to try them out.

And now I’m used to the way Foundation does things. I know how to do what I want in Foundation, so even if one of the other frameworks might be “better” for a particular project, I’m probably better off leveraging my existing experience with Foundation and bending it to fit the needs of the current project than to invest the time required to learn one of the others.

But if I was starting from scratch and trying to decide which one to use today, I’d probably discount Skeleton because Bootstrap and Foundation both provide so many useful extras. Using the provided components is much faster than reinventing the wheel and doing it yourself.

What it really comes down to is this: Can you live with Bootstrap’s style-heavy approach? And will the same framework be used in production? (This may not be your decision to make…) If so, then it’s more work (not for you, but still) to override Bootstrap’s styles to make it look the way you want.

If you want to learn more about using frameworks to create interactive prototypes, check out Livetyping, the online course that teaches UX designers how to make interactive, clickable prototypes using HTML, CSS, and Javascript.

You can buy Livetyping here.

Or sign up below for news about Livetyping, HTML prototyping tips, and more.

When NOT to Prototype

As I’ve been putting together Livetyping (my HTML prototyping course), I’ve been thinking about situations when you shouldn’t prototype stuff (interface elements, interactions, whatever). This two-by-two chart sums up my thinking:

When something is hard to explain, but easy to code, you should code it. When the opposite it true, you should explain it instead (maybe using something like Polypage to add annotations directly to your prototype). These seem to be no-brainers.

But the interesting bits are the other two rectangles. If something is easy to explain and easy to code, what should you do? And what if it’s hard to explain and to code? Well, it depends. And the “it depends” is similar for both cases.

It depends on why you want to prototype this particular bit of the interface. Is it just to communicate how it works to developers and stakeholders? If so, explaining is probably the best route.

But if it’s so you can test your design with users, it may be worth putting in the extra effort to code it, especially if it is used in any important flows. Of course, if you’re in the hard/hard rectangle, you may have to collaborate with your developer colleagues to bring it to fruition. (Thinking about it, this flavor of “it depends” applies to all four scenarios—if it has to be in there for testing, then it has to be in there.)

There are other axes to take into account, of course, such as the relative importance of the thing you’re contemplating prototyping, and the novelty of the element/interaction, but I’ve found this to be a useful tool for thinking about this stuff.

What do you think? Ping me on Twitter and let me know.

Livetyping is an online course that teaches UX designers how to make interactive, clickable prototypes using HTML, CSS, and Javascript.

You can buy Livetyping here.

Or sign up below for news about Livetyping, HTML prototyping tips, and more.

Time to Dump Wireframes 2: The Turning Tide

If you’re still not convinced that prototyping is better than wireframing (even after reading this?!?), here are a couple of great articles that were published recently that you really must read.

In the first, Sergio Nouvel gives a good overview of the pros and cons of each of the different fidelity deliverables that we are used to producing. He then goes on to make a compelling argument for starting out with lo-fi mockups, then going straight to “wireframing in the browser”, which has a number of advantages:

• With CSS frameworks, basic layout is a breeze.
• Your deliverable is responsive-ready.
• You can take advantage of what the browser does by nature.
• It’s truly interactive.
• The scalable nature of CSS enables easy, live changes.
• You don’t need proprietary software or a powerhouse machine.
• Everything you do saves you time later because you are building the real thing.

The second article, by Leisa Reichelt, is a punchy, tour-de-force list of reasons why prototyping beats the pants off wireframing. It’s a really quick read—already condensed down to its essence—so I won’t ruin it by trying to summarize it here. Just take the two minutes and go read it over on The Pastry Box Project. It’s really good.

Happy reading :)

Livetyping is an online course that teaches UX designers how to make interactive, clickable prototypes using HTML, CSS, and Javascript.

You can buy Livetyping here.

Or sign up below for news about Livetyping, HTML prototyping tips, and more.

How To: Prototype an Animated Notification (à la Twitter)

Tip: Switch to full-screen, otherwise you won’t be able to see a damn thing :)

This is a short excerpt from Livetyping, my self-paced video course that teaches you (the UX designer) how to prototype in HTML, CSS, and Javascript.

You can buy Livetyping here.

Or sign up below for news about Livetyping, HTML prototyping tips, and more.

Recording Mobile Screens—Another Option

Recording the screen of a mobile device is not an easy thing. You can build a fancy test rig, with cameras and so on. But it’s expensive and cumbersome. There are iOS apps that let you record the screen. But the ones I’ve seen are either buggy as hell or require you to jailbreak your device.

But today I came across another option. AirPlay lets you mirror your iPhone or iPad’s display on an Apple TV. But you can also mirror it on a Mac, using a product called AirServer. The company that created it promotes it as a way to play multi-player games with your friends on a nice big screen.

But with your device’s screen mirrored on your Mac, you can use screen-recording software (like Screenflow, Camtasia, or Morae) to record it. Which, for user testing, is pretty damn handy. (The image above was captured from my Mac’s screen.)

(Disclaimer: If you use the above link to download and install AirServer, my free trial gets extended by three days. Just so you know.)

Cool things happen when you point the iOS 6 panorama camera out the window of a speeding car

new-aesthetic:

Cool things happen when you point the iOS 6 panorama camera out the window of a speeding car

Twitter / drcongo (via Ben B)

(via ecotone)