As we’re sure you can guess – the team has been pretty busy over the past few weeks flying out to LA, working with editors and Funny or Die to complete our latest project: Pepsi NEXT’s Internet Taste Test.

Between three shoots out in LA, endless hours editing and uploading, the team pulled together over 480 videos of our Funny or Die improv actors trying out Pepsi Next for readers like you. 

We’re all finally back to normal, caught up on sleep and looking back as to how awesome this really was. We thought it’d be fun to share with you some of the results as well as some pictures and fun facts about the campaign we really loved. Enjoy!!

Now on with our favorites:

We’re super excited to announce today the launch of a project we’ve been working on with Pepsi’s newest product: Pepsi NEXT, a cola with real cola taste and 60% less sugar.

Everyone should head over to Facebook.com/PepsiNEXT to participate in the world’s first Internet Taste Test proving the product premise, “Drink It To Believe It.” By clicking through you are entered for the chance for noted LA improv actors do their best impression of you trying Pepsi NEXT for the first time, using information from your Facebook profile.

The Barbarian Group, in partnership with our friends over at Funny or Die, produced the real-time campaign that features Rob Riggle, with humorous (and sanctioned) impressions of notable pop culture figures like Internet mogul Gary Vaynerchuk, BuzzFeed CEO Jonah Peretti and a favorite internet meme here at TBG, Scumbag Steve.

The team here is so excited about this launch as it’s an example of how a big digital creative concept, rooted in social media, can launch a new brand to the masses. It’s a highly ambitious idea that, at its core, depends on spontaneous, on-set invention and large-scale video production in near real time.

We’re excited that Pepsi NEXT came on this wild ride with us.

It’s Gonna Be Awesome.

I submitted my first ever JS1K competition entry. Really, my first javascript or any kind of programing contest entry. And I’ll admit that it was quite a challenge too. It was like a putting together a jigsaw puzzle that you have extra pieces to. For my entry, I decided to take something that I worked on previously and rework it into something that fit the theme and into the 1024 byte limit. The theme for this year was love, so what I did was reworked the spider webs explorations that I had previously worked on into a heart shape and simplified it a bit. I also stripped out anything that wasn’t pure javascript. In the process, I was able to reduce my demo from 25K (not including the processing and toxiclibs js libraries) down to 1022 bytes.

The life of a digital creative is no walk in the park. Cranky clients, fire-breathing creative directors, and the occasional warping from design work to development (with a side trip into content delivery); these are just a few of the everyday trials and pitfalls of the industry. After a while, the whole thing can start to feel surreal, almost like a video game.

We wouldn’t be video game connoisseurs worth our Triforce if we didn’t do something to try and help. So along with our friends at Vitamin T, we’ve provided a walkthrough to help put the world of a digital creative into perspective.

It’s everything you’ll need to help navigate the careers and skill sets across design, development and content delivery. It is important to begin with a character that will maximize your talents, because even though you may end up knee-deep in code eventually, attacking development with the wrong skills at the wrong time can be an intense challenge. But don’t worry. There are infinite possibilities to explore, and a few odd secrets, as well.

I recently spent the weekend with some friends whose teenage daughter has lost all but a shred of her vision. It is very likely that eventually she will be totally blind. I was amazed to see how well she adapts to a sighted world but still couldn’t help but reflect on the designs I create and wonder whether she can experience them fully.

Around the time of the last internet boom, bubble and burst the discussions I remember weren’t about web standards, but web accessibility. Flash was extremely popular but because it was a plugin that didn’t expose it’s code structure to the browser, screen readers for the blind couldn’t make any sense of it. As far as they were concerned a Flash object was no different than a single static image.

Today I am shocked to find that many of the younger designers I talk to aren’t aware that the ‘alt’ tag assigned to images in HTML was created so that screen readers could describe the image to vision impaired users. It seems to be thought of as another place to add marketing. A branded opportunity for when the mouse hovers an image.

Now in the wake of CSS3, HTML5, and closer browser alignment to standards the notion of ‘responsive web design’ seems to be the discussion of choice. I’ve even blogged about it. Responsive design is a great thing as it brings accessibility issues to the forefront. Specifically the accessibility of smaller screens, but combined with the latest coding practices the environment for visually or auditory impaired users is now at it’s greatest.

As interaction designers, coders, and creatives we need to be aware of everyone who may want to use our designs. We need to consider smaller screens, the elderly who rely on hearing devices, and a blind teenager who one day wants to be a writer and ask ourselves, is this design good enough for them? Am I being a dick?

Don’t be a dick.

I’m proud to announce the release of The Barbarian Group’s first android app, Gastrodamus. This of course is the Android version of the food truck tracking iPhone app that was released last month. It has all of the same features and food trucks that the iPhone version has, but now works on your Android 2.1+ devices.

I have a certain… paranoia when it comes to “cloud” services. Especially the likes of Dropbox, iCloud, etc. The services that “just work.” However, I recognize the value of these services and would actually find them extremely useful. So one day I thought to myself, “Man I really need to solve this problem of having files that I need for my personal life tossed all across four (yes 4) computers.” And then I thought, “Maybe I should just give in and use Dropbox…” Of course then I read things like this and this. It isn’t that I have top secret military project files or anything, or that I have a bunch of illegal business goings on that I need to hide from law enforcement, but it is personal information. Stuff that anyone would care to have backed up in a safe, secure location, like banking information, taxes, passwords, etc. Stuff that you would want access to at the drop of a hat from any computer you were on. So…

I’ll make my own dropbox. Using my own server, and free open source software. Here is the process.

First you’ll want to have a server setup and hardened. Hopefully you’re able to do that because the process is too long for this guide. My personal dropbox is made up of 3 pieces of software, git, gitosis, and SparkleShare. You’ll also need to have SSH configured to use authentication keys instead of passwords.

For sake of ease, let’s say we’re using a 10.04 Ubuntu fully updated and patched server. First we want to install git so run:

Now that we have git installed we can grab the latest version of gitosis:

Now we have the source for gitosis downloaded we need python and setup tools:

And now, from the gitosis directory, we’ll install gitosis:

Cool. Next we need to set up a user to contain our repos and manage our ssl certificates. This user can be whatever, but for sake of ease in this tutorial we’ll just call it “git.” The home directory can be where ever you choose as well, but again, for sake of ease in this tutorial we’ll just put it in /home/git.

That’ll create the user, the group, and a homefolder. It will also disallow password authentication which means we’ll have to use key authentication. Now we’ll have to add our first public key to gitosis so that we have admin access. First copy the public key of the machine you are working on up to the server and run the following where “my_kefile.pub” is your public key:

That command will load the git user $PATH (important because we are running the gitosis-init binary) and run the gitosis-init binary as the git user. That will create our first git repo, gitosis-admin, and add our key so that we have access. Now a little cleanup. Every other gitosis install guide will tell you that you need to make sure the gitosis-admin post-update hook needs to be made executable. It has always been fine for me, but just incase run:

Alright! That is it for server setup. Good job. Let’s head back to your workstation now. Hopefully you have git already installed on your workstation, but if you don’t head here and download the appropriate installer. Crack open your terminal application and run the following:

This will clone the gitosis admin configuration down to your computer into the directory you are currently in. If you cd into gitosis-admin and have a look around you should see a “keydir” and a “gitosis.conf” file. The keydir stores all the public keys that will have access to your git repositories. The gitosis.conf file is where you set up and configure access to repositories.

First let’s check out how repos are set up. Open up the gitosis.conf file. You should see the default configuration there already, it looks something like:

the [group ..] definition is an arbitrary definition, it can be whatever you want. Next “writeable = ... ” defines the name of the repository that is writeable by the group, in the default case the gitosis-admin repo. Finally “members = ... ” defines the keys that are members of the group, they are the filename of the key minus the .pub extension. So in this case I have a file in the “keydir” directory called “nick_macbook.pub.” I’ve made it a member of the group “gitosis-admin” which has writeable permissions on the repository “gitosis-admin” (write-ability implies read-ability in this case).

Now let’s set up our dropbox repo, add something like the following to gitosis.conf:

Save the file and head back to terminal and run:

We just entered the gitosis-admin repo, committed the changes we made to gitosis.conf, and then pushed them up to the server. By doing that we created a new git repo that will become our “dropbox” folder. Sweet!

There is a lot to gitosis, but just know that you can add more keys to the keydir, then add the file names without the .pub extension to the “members” definition of any group to grant that key access to the group’s repository.

Finally let’s set up SparkleShare. Once you’ve downloaded the app and copied it to your applications folder, fire it up. After you do that SparkleShare will ask you to set up a remote folder. The “Address” will be your server’s hostname, and the foldername will be the name of the repository we just set up, in this case it is “dropbox.git.” As long as you have your keys set up properly in gitosis, when you hit “sync” SparkleShare will create a new directory in your home folder and boom! You’ve got a drop box. Add any files to that folder and SparkleShare will automatically commit and push them up to your remote server. It’ll also periodically pull down whatever the server has that the local working copy doesn’t. Neat eh?

A Couple Notes
You’ll obviously have to configure your firewall to allow traffic on port 22 for this to work. If you’re having trouble pulling down the repo in SparkleShare, did you remember to push your gitosis conf up?

Have you ever completed a flash project and started testing it online only to realize that the swf is looking for assets either in a different directory than the one you specified? Or that the folder that you have all your media stored is not in a relative directory like it was when working on it locally? There’s an easy solution that can be implemented without messing with any actionscript code.