Topic: Tips and Tricks
Grouping Layers Magic with Photoshop Actions
At Viget we have Campfire rooms set up for each lab. We designers use our room to share designs that we're working on, post links to sites that we want to discuss, and general chatting to keep the connection between our offices close. But one of the things that I love the most is how we lean on each other for help with technical questions. A Photoshop question came up the other day asking if there is a shortcut to group layers, and then have the Group Properties box open to make grouping and naming the new group using a single keystroke. Seems simple enough, right? Wrong.
Keyboard shortcuts only work with one command at a time. So grouping layers (Cmd+G or Ctrl+G) and opening group properties (Cmd+R or Ctrl+R) work fine individually, but it breaks down when you want to do both using a single keystroke. Luckily we have Actions, which work brilliantly in this situation. Assuming that you have at least a basic knowledge of creating actions in Photoshop, I'm going to jump right to the good stuff. (Go here for more information on creating actions.)
Continue reading "Grouping Layers Magic with Photoshop Actions"
Critiquing Design With Designers
A little while back I wrote an article about critiquing with non-designers, which might be better described as "cross-disciplinary critiques." As many designers know, the art of critique is difficult to master but important if you want to get the most out of your designs. At Viget, our designers hold this art in high esteem. We value cross-disciplinary critiques, but we also love to conduct designer-to-designer critiques as an early checkpoint. In the past year or so, we've been more deliberate about doing this, and, while still a work in progress, we've learned quite a bit about what makes for an effective critique. Here's a look at what we consider essential to good designer-to-designer critiques.
Handing Off PSDs That Won’t Make Your Co-Workers Hate You
Once upon a time, I worked as a humble barista in a cafe. For those who have not had the privilege of working in the glamorous world of the foodservice industry, let me explain a little about one of the processes. There was a closing shift and an opening shift. Closers were responsible for cleaning up at night, shutting down all the machines, washing the floors and tables, taking pastries out of the freezer and putting them in the refrigerator so they could defrost overnight, basically making the cafe immaculate and ready to be opened in the morning. Openers did everything to get the cafe back up and running the next morning; they had only an hour before the store opened to set out the pastries, turn all the machines on, make the morning coffee, etc.
I was an impeccable closer. Consequentially, the times when I was the opener, nothing infuriated me more than a shoddy closing job. I only had a limited window of time to get everything on, out, and running, and some lazy closer had left last night's dishes out, bagels were still frozen, countertops were filthy. My job that morning had just immediately become doubly difficult, behind schedule, chaotic, (and gross), all because last night's closer didn't care about the mess they were leaving for me.
I'm going somewhere with this, I promise. Almost there.
As a designer I create a comp in Photoshop and when I'm "closing" on my part of the project, I'm handing my PSD off to one of our front-end developers. They then take it, get it up and running and into a real website. Just like back in the cafe, I want to have an immaculate PSD to give to them, so that they can work easily and efficiently, and not curse my name. (The same thought applies to other designers who might have to handle my PSD to make updates to a design.) A PSD that I'm giving someone else to work on should be easy to understand and make perfect sense to someone else.
So what's the best way to organize a PSD when it's handed off for development?
Continue reading "Handing Off PSDs That Won’t Make Your Co-Workers Hate You"
Timesaver: Launching Sites with Alfred
We have a long-standing history of being as efficient (*cough*) as possible here at Viget (see here, here, and here). We also have an ever-growing number of web apps and project-specific resources to monitor and update throughout the day.
Manage those project links via Bookmarks and your folders start to rival Craigslist in terms of elegance and efficiency. Physically type (let alone remember) the URL? Come on...who has that kind of time?
It was only a matter of time before I started looking for shortcuts.
SimpleVideo - a jQuery Plugin for Simple HTML5 Video Control
While working on a recent client project I finally had the chance to use HTML5 video for a demo video on the homepage. We wanted a simple, no controls player with a Play button overlay. After some digging I found that while HTML5 is pretty well-supported in the latest and greatest browsers, out-of-the-box implementations don’t offer up a lot of control for external controllers or onPlay and onPause events.
I checked out a few publically available packages like VideoJS and Kaltura’s HTML5 Media Libary but everything I found seemed to cover too much of the spectrum. Building timeline scrubbers, volume control, and full playback controls into their libaries was just too much overhead for my little audio-less demo video.
In order to have something that was lightweight and easily portable between projects in the future, I put together SimpleVideo - a tiny little (100 line) jQuery plugin that wraps some much needed event control around the HTML5 video object.
Continue reading "SimpleVideo - a jQuery Plugin for Simple HTML5 Video Control"
Docs That Work (Everyday Techniques No. 2)
Any degree of design or development requires some level of documentation — documents that aren’t the work itself, but are either requirements or helpful aids in the process. Documentation builds project value as a handoff, a sales tool, a client satisfaction point, and as a simple internal tool: It's a key part of web design and a key expectation clients should have when they approach you for work.
My problem with it? It sucks. Documentation is a snore: painful to create, painful to read, and (more often than not) it goes obsolete and unappreciated once you’ve finished.
But documents can work well with your project, if you keep two goals in mind:
- Do as little work as you can
- Make docs that do as much work as they can
I divide design/front-end documents into three categories, each of which have opportunities for maximum laziness and high ROI:
Continue reading "Docs That Work (Everyday Techniques No. 2)"
Simple jQuery Refactoring
Since we have a front-end development (FED) team at Viget now, we decided that we should have a weekly team meeting. We decided that we didn't want it to be just a typical meeting, so we have "FED Sacrifices". The way it works is that one person puts up a piece of code, gives a little background on what it does, and then everyone just tears it apart to figure out how to improve it. It has been fantastic, and now we argue over milliseconds of speed improvements. I am a much better coder because of it.
I've really only been using jQuery heavily for 2 or 3 years, but after about a year at Viget and a few months of FED Sacrifices, I have drastically changed how I use it. Before using jQuery, I did a fair amount of DOM scripting, but after seeing how much jQuery could simplify things, I made the switch. So I read through tutorials and copied code; that was how I learned how to use it. The code that I learned to write looked a lot like this:
Note: Line wraps added for readability.
$(document).ready(function() {
$('#nav > li > a').click(function() {
if($(this).parent().hasClass('current')) {
$(this).parents('#nav').find('.current')
.removeClass('current');
$(this).parents('#nav').find('ul:visible').
slideUp(250);
} else {
$(this).parents('#nav').find('.current').
removeClass('current');
$(this).parents('#nav').find('ul:visible').
slideUp(250);
$(this).parent().addClass('current');
$(this).siblings('ul').slideDown(250);
}
return false;
});
});
There are a few things wrong with this, so let's step through them one by one and see how we can improve it.
2011