Charlie Whitney, an internet-friend-turned-real-life-friend, recently finished the Urbandaddy Cycling Classic installation for the E2NY Music and Arts festival. It takes two racers on modded bikes and projects virtual environments mapped to their speeds. The concept is awesome, the execution is perfect, and it just looks so fun. If I still had birthday parties, I’d want to rent it for my upcoming 25th.
These past few months, I’ve been beta testing Gimme Bar, a new web service by FictiveKin (the same dudes who developed TeuxDeux). This time they’re targeting internet content. At first, Gimme Bar might seem like just another bookmarking service, but instead of linking to the content, it actually saves it. You can save text, images, videos, and even capture an entire webpage.
What I love most about Gimme Bar is that there’s no specific way to use it. At first, I thought I’d make a wishlist for gadgets, but over time, it naturally became a collection of my favorite animated GIFs. There are countless ways you can use Gimme Bar and that’s what excites me about its future.
Gimme Bar is still in beta, but you can sign up without an invite for today only. Jump onboard while you can and try it out for yourself.
In my experience, version control is one issue that has always existed in the design world. Since devs are used to obscure commands and “mentally-challenged” user interfaces, typing git add . & git commit -a isn’t a big deal. Designers are different. Save as... is the typical version control method for many, and any attempt to force designers to use p4v might lead to mass suicide.
LayerVault tries to solve this problem by plugging directly into Photoshop. A simple Command + S automatically saves a revision. Then, you can view the file’s history in a timeline interface that shows a clear diff of the changes.
Unfortunately, LayerVault is currently in a closed beta, so I don’t have any invites to hand out, or even one for myself! For now, you can watch the video below, apply for access, and cross your fingers.
Today, Wacom introduced a new device called Inkling. It clips onto your sketchpad, records what you draw, and instantly provides a digital copy of the drawing. It sounds like black magic, but if it actually works, I know first-hand this will be on the wishlist of every illustrator out there. Check out the video below for a closer look.
I work with a very talented designer, Kim Pimmel, who consistently knocks out killer work both on the job and in his free time—we share the same hunger for side projects. Earlier this year, he started a short film series titled, “Compressed.” Kim released his second of the series and it does not disappoint. Even after telling me exactly how he did it, I’m still dumbfounded. Below are a few stills along with the film.
Last month, Adobe’s XD department held a ‘hack day’ for developers. Since we only had one day to produce something, I planned ahead and aimed to turn a vintage Simon Says into a build server status indicator. Since patience isn’t my greatest quality, I finished the project weeks before the hack day. I’m glad I did since I had to order many additional parts I didn’t think I needed.
The indicator works by cycling through the colors if the server is building. When the build succeeds, the indicator flashes green. When the build fails, the indicator flashes red. I used an Arduino Uno with a battery and bluetooth modem to make it completely wireless, so it could just hang on the wall, waiting for a build to start. Unfortunately, bluetooth eats through batteries like I eat through burritos, so that foiled my plans. As a tethered device, it’s not exactly practical, so it will lie in a box until the next time I show it off.
If you’d like to take a closer look at the process, visit the lab page.
Since launching the new site and getting back into the blogging game, timing has been very important to me. Most importantly, what is the best time to tweet about a post in order to get the most exposure? This is where Crowdbooster comes in handy.
Crowdbooster is a web service that analyzes your tweets and your followers’ tweets, then generates a bubble chart, indicating the time of the day in which your followers are most active. From there, you can schedule a tweet and avoiding waiting for the right time. It also provides a slew of other data, like follower count over time and retweet impressions, but scheduling has been most useful for me.
At the moment, Crowdbooster is invite-only, but I have five invites to hand out to those interested in trying it out. Since the invites require me to type in email addresses rather than simply link you, I’m going to make it interesting. In the comments, link to your favorite animated GIF and I’ll pick my five favorite. And, by animated GIF, I don’t mean those under construction ones from ‘95. This gem is what I want to see.
Like many developers, I’m OCD about code quality—not only for performance, but appearance as well. When working with generated HTML, it’s difficult to make sure every mixin, include, or partial is correctly indented. Enter Tidy, an HTML-cleaning executable that oddly enough comes bundled OS X. Here’s an example of the syntax:
$ tidy -im index.html
In the above code, the -i flag tells Tidy to properly indent index.html and -m indicates that Tidy should directly modify the file.
This is all well and good for an individual file, but what if you’re working on a large website? Luckily, Bash makes it easy by using a glob, or wildcard. This snippet executes Tidy recursively over every HTML file in the working directory:
$ tidy -im ./**/*.html
Now, if you’re working in a language like Ruby, you probably don’t want to use the command line if you can help it. There are several Ruby Gems that can run Tidy on a string or file, but I’ve had the best luck with Tidy FFI.
For this site, I run Tidy FFI at the tail-end of my Rake script, automatically cleaning up the innards and giving my OCD side some peace of mind:
require 'tidy_ffi'
desc "Tidies HTML files"
task :tidy do
Dir.glob('site/**/*.html') do |path|
content = File.open(path).read
File.open(path, 'w') {|file|
file.write TidyFFI::Tidy.new(content,
:numeric_entities => 1,
:output_html => 1,
:merge_divs => 0,
:merge_spans => 0,
:join_styles => 0,
:clean => 1,
:indent => 1,
:wrap => 0,
:drop_empty_paras => 0,
:literal_attributes => 1).clean
}
end
end
My script sets a handful of parameters that actually prevent Tidy FFI from cleaning too much. If you’re not careful, it will merge elements, and royally screw your CSS if you use nested selectors. View the site’s source code and see first-hand how well Tidy cleans!
Continuing the Jekyll series, today, we build our first Jekyll website. So, where to start?—install the dependencies!
There’s a more extensive list of installation instructions on Jekyll’s wiki for those with a hipster OS, but I’ll get the majority of you started, assuming you already have RubyGems installed. Simply install the Jekyll gem via Terminal and it’ll grab all the other gems that Jekyll requires by default.
$ gem install jekyll
Create a new directory and cd to it. Create a file, index.html, and insert the following code:
<html>
<head>
<title>Hello world!</title>
</head>
<body>
<h1>Hello world!</h1>
<p>This is my first Jekyll website.</p>
</body>
</html>
If you run jekyll now, Terminal should spit out a warning about a missing _config.yml file—ignore this for now. Terminal should also indicate a successful build of the site, creating a _site directory with your index.html in it. And just like that, you compiled a Jekyll site in the simplest form.
As-is, you should be able to open the index file in your browser of choice and see the result. However, as you dive deeper, you’ll want view it as one would see it on the web. Jekyll gives you the option to run a server on localhost, providing a real-life testing environment. Simply add --server $port to the end of your jekyll command, replacing $port with the port of your choice. I use 1337 for the obvious reason—I’m a baller.
Note - Jekyll’s server disregards .htaccess files, so if you rely on one, I’d suggest using an app like MAMP. It’s free and doesn’t require you to keep a Terminal tab open.
Along with --server, you can add --auto to make Jekyll watch your source folder for changes. If it detects any movement, it’ll recompile. I don’t use auto-mode as much as I should because it only indicates when a file has changed, not when the recompile has completed. For larger sites, I prefer to know exactly when the new content is visible.
By default, Jekyll uses the source files from the top-level directory and outputs the generated files to that _site folder. I’m not a fan of this, so I use a different file tree that I specify in the configuration. I suggest you do the same by creating a _config.yml file in the top-level directory and adding the following code:
source: ./src
destination: ./site
Now your source files live in the src folder and your generated files live in the site folder. Move your index.html file to the source directory, run jekyll, and the file should now appear in site.
There are a ton of parameters you can set in the config file, but I’ll only touch on these for now. If you’re curious like me and want to jump ahead, check out the list of options on the wiki.
Note - Jekyll disregards any directory or file prefixed with an underscore, which is why it doesn’t copy the _config.yml file into _site. Keep this in mind going forward.
Layouts are one of Jekyll’s high points, especially when nested. Start by creating a _layouts directory inside of the source folder. Make a default.html file, which will (obviously) be the default layout used by your pages.
Copy the contents of your index page to this file, but replace the title and body, like so:
<html>
<head>
<title>{{ page.title }}</title>
</head>
<body>
{{ content }}
</body>
</html>
Jekyll utilizes Shopify’s Liquid framework for variables and processes within a page. I’ll be sure to write a post dedicated to Liquid, but for now, you might want to familiarize yourself with it.
Every layout must contain a content tag, telling Jekyll where to place a page’s content. As mentioned in the intro, you can nest layouts, where a layout’s code will replace its layout’s content tag. It might sound a bit confusing right now, but once you use it first hand, you might find yourself tap-dancing with joy.
The above code also inserts the page’s title inside the <title> tag. Jekyll provides a slew of variables, detailed on their template data wiki page. Pretty much any metadata you specify in a page’s metadata can be accessed with the page variable.
After adding your first layout, return to your index file and replace it with the following code:
---
layout: default
title: Hello World!
---
<h1>Hello world!</h1>
<p>This is my first Jekyll website.</p>
There are two parts to a page—the metadata and the content. Jekyll uses YAML to set variables for each page. It’s like XML, but without the opening/closing tags. Also, it’s very strict when it comes to whitespace, so take a moment to read up on it if you’re unfamiliar.
The metadata lives between two sets of three dashes, as seen above. Those dashes indicate that Jekyll should process this page. Before, when we had plain HTML files, Jekyll only copied the file without processing it because it lacked the dashes. In theory, you could have a page beginning with two lines of dashes, the content, and nothing else. Even so, you should, at the very least, specify a layout and title.
The content then lives below the metadata. For pages, the content must be HTML. It could be other formats, like HAML or Markdown, as long as you include the appropriate converter, which I’ll touch on in a future post.
Run jekyll one last time and it should generate the same content we had when using the plain HTML file.
I’m going to stop myself here before I go beyond a simple ‘hello world’ example. If you have any questions, be my guest and ask away in the comments. In the series’ next post, I’ll help you build your first Jekyll blog, utilizing ‘posts’ instead of ‘pages’ and Liquid loops. Until then, experiment!
Thumbnail photo by oskay
The best part of releasing a website or app is getting to the point where you can casually tweak things. I decided to have a little fun and set image backgrounds to the checkered canvas Photoshop uses to indicate transparency. It’s incredibly simple, requiring only a repeat background in CSS, but effective nonetheless. Below is the code and you can download the checker asset here. Feel free to use it on your own site.
img
{
background: url(/assets/checker.png);
}
