Sometimes I have too many things going on on my computer and need a fresh start. I don’t want to go through every single Photoshop file, Safari tab, iChat conversation, text file, etc. to review changes and individually quit everything. I just want everything to go away. Without saving. And I want my computer to turn off. I want to start over.

Previously when I felt the overwhelming need for an immediate fresh start, I would just hold the power button in for a few seconds. This isn’t very good for your computer, though. It’s better to let each application properly quit and your disk to spin down. So I made an Automator application that does just this.

I call it Kill Start. When you run it, everything dies. No annoying dialogs. No force quitting. No waiting. No apologies. Your computer turns off, and then it turns back on. Anything you failed to save previously is lost forever. Sometimes that is the desired effect. If you ever have this desire, then Kill Start is for you.

Download version 1.0 (279k)

A few weeks ago, Jason Fried of 37signals caused a mild stink by blogging about why his company doesn’t comp their designs in Photoshop:

…we’ve found that going straight into HTML/CSS affords us the best iterative and creative experience. HTML/CSS is real in a way Photoshop will never be.

Be sure to skim through the comments.

One thing I think web developers tend to miss when reading Signal vs. Noise is that 37signals isn’t a web development company, they are a software company. The majority of web developers build custom websites/web applications for clients. 37signals (primarily) makes hosted software based on what they think is useful, intuitive, and powerful. They make the rules, they decide how it works, they get to make it look the way they want it to look. As far as the design of their product goes, they are essentially their own client. Yes, they need to deliver a product that makes their user base happy, but those details are largely usability related, not texture, drop-shadow, serif, help me sell my sunglasses to 20-something surfers related.

I don’t think for a minute that 37signals should cater their blog to web developers, nor do I think they should attempt to clarify this difference in their blog posts (not when posts like the above play off this confusion and increase ad revenue). There is an endless universe of web developer resources online. They are a wholly unique company. If any one company should have a blog that celebrates what makes them unique, it should be them.

I think it’s more important for web developers to remember what they are reading. And for those web developers having trouble remembering why it is they do what they do, allow me to offer my list of why we scrutinize every detail of every project in Photoshop before going to build:

1. Delivering a product that isn’t anything close to what the client envisioned is a product you have to build again. Building a project more than once, but getting paid only once is bad business. In our experience, laying out exactly what the end result will look like weeds out all the discrepancies about how information will be displayed in every possible state. Doing this after the fact can often require significant changes to back-end logic. Changing the format of a date in a smart layer in Photoshop is infinitely quicker than changing database queries, CSS, and PHP/Ruby/Python/C# code, and then changing it back when the client decides they liked it the old way better.
2. Not every client has contracted a website before. Many of them are clueless as to what is even possible on the web, or possible within their budget. “I wanted ITC Berkley Oldstyle for the body type, just like our brochure!” Again, weeding all these limitations out in the design phase is much more efficient that recoding a framework after the fact.
3. The PSD files used to build the site comps can be directly exported for the web to use in the style sheets and as embedded content in the actual site. All of the graphic elements have to be built anyway, and it is much easier to build them in context with each other.
4. Fleshing out various states of a particular element is often critical as well. Not every page we build is static. In fact, no pages we build are ever static. At the very least, each anchor element on an html page will have a hover state. Popup menus, tool-tips, context menus, zooming image widgets, all of these things need to look like something, and their graphic elements need to be created somewhere.
5. Most people like to see site elements a few different ways before deciding on what they want to go with. Often times it’s helpful to see them side by side during this process. Coding three versions of a page and displaying them side by side is not faster than pasting and dragging around a few layers in Photoshop.
6. Starting build before final designs have been approved, and more importantly—signed off on, has cost us more money than I would probably be allowed to say here. It is mostly because of this that I can say without a doubt, not presenting your client with a comprehensive visual representation of what their finished site will look like before build begins could put you out of business.

The look and feel of products like Basecamp, Highrise, and Backpack can easily be achieved in strait XHTML and CSS. I can see how jumping right into development builds could be a more efficient way to design those types of projects, especially when you are building on top of a sweet MVC framework like RoR. In the real, non-in-house designer world, however, clients rarely want their websites to look like computer software. Do you think Cuban Council designed Suicide Girls without Photoshop?

Further, you don’t always have control over what platform you are designing for, or what kind of markup you are being handed. Not every platform is as agile as RoR, nor are you always designing a brand new site, its logic or markup structure.

In the past two years, 2 of the 40 projects I worked on actually warranted a simplistic, utilitarian design. Even in these cases, compositions were created in Photoshop or Fireworks first. The simple fact is our clients hire us to design them something, and clients like to change their minds about what information they want displayed where.

I love reading Signal vs. Noise, but it is plainly obvious that 37signals is anything but a web design company.

Over a few months ago, I attended the Kanye West: Glow in the Dark Tour. It was his second stop of the tour, right after Seattle, and I must say, I was truly impressed. It’s hard to describe the hype surrounding this show, but if anybody follows Kanye even a little, they are probably aware of his cocky demeanor, his “my-shit-smells-like-roses” attitude and his gift of saying what everybody is thinking–rude, un-PC, strangely inappropriate or not. You have got to admire a guy that just “does not give a fuck.”

Arco Arena in Sac is not a giant arena by any means, but it was still a packed show. Kanye def draws a cult like following, but spread on all levels of a spectrum: hip-hop heads, indie kids, sporty ballers, bro-brahs, old and young alike, everybody was there for a much hyped show.

Did you guys know, that Kanye is the next Tony Robbins? We were handed a leaflet like book, filled with Kanye-isms. An entire 52 paged book filled with his outlook on life, words of wisdom, and his “secret” to success. Great down to earth “isms”, the book is also equally filled with laughable bullshit.

Time for the show! It was everything the reviews said it was..in total kanye fashion. His band was below him in a pit. He gave one shout out to them, but never introduced them individually. He was the only guy on stage. Just him..no hype guys, none of of that. Just kanye for the crowd to be mesmerized. Simple stage, the platform he’s standing on raised about 10 feet, but no flying or acrobatics or none of that shit. It’s weird, you can see it in his face at times, that although he’s a genius, he’s totally in a world of his own. He seems totally out of touch with reality. But he can perform…one of the best concerts I’ve ever been to. the thing I liked most, is that his music came first, then his showmanship. Never did he throw a bunch of fancy, showy flair at us. No flying from the rafters. No Cirque du soliel shit. His set was about an hour and a half, with no wardrobe changes or breaks, he didn’t leave the stage once. He was as sweaty as boxer who went 10 rounds. Overall, loved it. One of the most breathtaking performers I have ever seen.

P.S. I recently had the pleasure of attending one of country’s biggest stars and one of our favorite clients, Kenny Chesney in San Francisco which was regarded as the western U.S.’ biggest country event. At my rate, I’ll get some kind of review in about 3 months. On that note, I will just say, “I think I might become a country fan.”

Check out some pretty shitty photos from my iPhone at the concert.

Lets say, you are making a site, were everything is AJAX, and you rely on event handlers to know when people double click on this element, drag the image across the site, etc. Normally you would start listening to things once the DOM fires (when the page loads), but problem is, it only fires once. Here is an example of a normal “onload” listener in Prototype.js:

Event.observe(window, 'load', function () {
	$$('tr[rel="file"]').each(function(element) {
		element.observe('click', function(event) {

			new Ajax.Request('file_info.php', {
				asynchronous: true,
				method: 'get',
				parameters: 'ajax=true',
				onComplete: function(t) {
					$('files').update(t.responseText);
				}
			});
			event.stop();
		});
	});
});

So, once the window loads, tell every table row with the rel attribute named “file” to some things once its clicked (in this case, gets the file info). Problem is, with all the new table rows coming in, Prototype wasn’t told to listen to the new table rows, only the previous ones that are gone.

I spent about an hour trying to figure out how to re-load the observe above. With tension building, I finally found something in the Prototype API documentation. You can establish your own psuedo type observation, which you would call when the window loads! Here is an example:

document.observe('start:files', function() {

	$$('tr[rel="file"]').each(function(element) {
		element.observe('click', function(event) {

			new Ajax.Request('file_info.php', {
				asynchronous: true,
				method: 'get',
				parameters: 'ajax=true',
				onComplete: function(t) {
					$('files').update(t.responseText);
					document.fire('start:files');
				}
			});
			event.stop();
		});
	});

});

Event.observe(window, 'load', function (event) {
	document.fire('start:files');
});

So when the window loads, it will load another observer. Although this seems redundant, it’s the only way to re-fire the listener when you need to. Let me note, that the start:files you can name it anything you want really, although it should have a : somewhere in-between it.

I was wrapping up on a project, and the time came where the color on the lists (1, 2, 3) needed to be different colors than the actual <li> inside needed to be. The only solution is to wrap any content inside the <li> with some sort of tag to target the text to change the color. Although that has no problem at all, what if this needs to be site wide? It will be very cumbersome to remember, let alone do it to every list you create.

I decided to use JavaScript to search for every <ol> and for every <li> inside of it, then it goes ahead and wraps it in the selector that changes it back to default color. In this case its a <span>.

This is what it does, this will be the before HTML:

<ol>
   <li>Item text goes here</li>
   <li>Item text goes here</li>
   <li>Item text goes here</li>
   <li>Item text goes here</li>
</ol>

And, after the JavaScript does its thing:

<ol>
   <li><span>Item text goes here</span></li>
   <li><span>Item text goes here</span></li>
   <li><span>Item text goes here</span></li>
   <li><span>Item text goes here</span></li>
</ol>

Here is the JavaScript:

window.onload = function () {
   var li = document.getElementsByTagName('ol');
   for(i=0;i<li.length;i++) {
      if(li[i].childNodes[1].nodeName == 'LI') {
         var li_count = li[i].childNodes.length;
         for(b=0;b<li_count;b++) {
            li[i].childNodes[b].innerHTML = '<span>'+li[i].childNodes[b].innerHTML+'</span>';
         }
      }
   }
};

Here is the CSS:

.container ol {
	padding: 8px 10px 8px 25px;
	list-style-type: decimal;
	color: #c19203;
	font-weight: bold;
	}
	.container li {
		padding: 4px 0;
		}
	.container ol span {
		font-weight: normal;
		color: #333;
		}

Max and I were having trouble getting our flex project synced up with flex. It kept throwing errors, like:

Error: Error while performing action: Can't copy '/Volumes/Files/Project/Assets/Wireframe/bin-debug/.svn/text-base/index.template.html.svn-base' to '/Volumes/Files/Project/Assets/Wireframe/bin-debug/.svn/tmp/index.template.html.tmp.tmp': No such file or directory

Finally we decided we need to just ignore the bin folders. That stuff gets autogenerated all the time by flex, so I think it’s a reasonable solution. This article has some related info, but it’s for Flex 2 and I don’t think it applies directly. For now I’m just doing the bin folders and seeing if that’s enough to stop the svn errors.

First thing I do is have my mail forward from gmail to an imap account on our dreamhost dev server. This is because I don’t like how gmail handles flagging. But essentially, I setup Mail.app to check my mail via imap. I leave my Inbox in threaded view and I use that for looking up old conversations. The crux of what I do differently is I have a smart folder named “To Do” that I am in most of the time and essentially my real inbox. Here are it’s settings:

Thus, this smart folder shows anything I’ve flagged and anything that is new. Also, when you unflag or read something it doesn’t disappear. So really, this todo folder shows all recent stuff as well, until you click to look at a new folder. In addition, I color code emails too using groups in my address book. Green is BKWLD, blue is friends, orange is family, etc. So, my todo mailbox ends up looking like:

This way I can quickly keep track of new things and stuff that still needs attention. And I achieve the zero stuff in inbox serenity if I can work through all the flagged and unread emails without having to actually move or delete things.

Continuing on what Mark started, I will explain how I do my email.

Mail is usually always open whenever I am here at the office, at home doing my own things, or on the iPhone. It’s hard to not be able to reach me. To be able to do this efficiently though, I setup IMAP on my email accounts rather than POP. IMAP allows me to be able to read a email on the go and mark anything I read as read, so later on in the evening everything I just read is marked as read so I don’t have to go through them all again. Same goes with deleting.

If I ever see a email in there, it bugs me not to look at it. I don’t do anything special with organizing my email, although I probably should. I just have a inbox for each of my accounts; BKWLD, .Mac, and my personal email.

One thing I tend not to do is delete email (other than spam of course), if I ever need to go back and look through my email I can. Although now with Time Machine, I can probably get away with it. If you have any suggestions, let me know.

There has been a lot of discussion round the office about how everyone manages email over the past couple of days. While the basic idea of email is pretty simple, the endless number of tricks people employ to wrangle their inboxes into a manageable state fascinates the ever-loving crap out of me. So I thought I’d share my tricks.

I’m a partial subscriber to Marilyn Mann’s inbox zero methodology. By partial, I mean I don’t really care about having zero messages in my inbox, but I do only turn on my email when I’m ready to go through and process all my new messages. By process, I mean put to-dos in my to-do list, put appointments in my calendar, respond to questions, and/or just plain do what I need to do so that I can delete the message and never think about it again; unless that message contains something I may want to hang on to, in which case I just leave it in my inbox after processing it. When I’m not processing my email, I quit my email program (I use Apple Mail to manage my 3 email accounts on all my computers via IMAP).

I don’t file emails into specific folders. Every email that I don’t delete, stays in my inbox. When I need to find something, Mail’s Spotlight search is 1000x more efficient for me than any amount of filing or color coding. To keep things easy on the eyes, I have a smart folder called Unread with a simple rule:

I use this Unread smart folder as my default email view. I read all of my messages in the preview pane, and have Organize by Thread enabled (this groups all messages by Subject). I keep my messages sorted by Date Received in descending order.

I also have two other smart mailboxes that I use less frequently:

• Flagged - all flagged messages in any mailbox
• Attachments - all messages with attachments in any mailbox

I’ve found that setting aside time to deal with and process email at regular intervals throughout the day has virtually eliminated my need to file or color code them in a way that makes them easier to find, simply for the fact that I have already dealt with them and no longer need to find them. When I do need to find something, a Spotlight query is simply faster than looking for colored subject line in multiple nested folders.

[Update] included some images.

I’ve been building two big ass sites for the past few months that both have auto-play elements on many of their pages. I work best when I can put the headphones on, but when iTunes is your main music source, listening to music isn’t very pleasant when you have audio that starts up every time you re-load a page. During the last phases of front end layout, I often have four or five browser windows displaying content. Multiple instances of the same audio playing at different intervals is horribly annoying, even if it’s a song you still enjoy after the 9000th time you’ve heard it.

My professional recommendation as a web developer is to not auto play media on your page. It’s annoying, it can be jarring late at night, and it can get you in trouble at work. These seem like things you generally wouldn’t want to do to the people supporting your site/business. But the customer is always right, and I aim to please.

Enter Audio Hijack Pro. I’ve been using Audio Hijack to some degree for years to capture audio from various applications on my computer, but until recently, it never occurred to me to use it for controlling live audio—or more accurately, muting the audio of a specific application!

Now that I can mute Firefox, Safari, and my entire virtual Windows machine, iTunes can have free reign of my system without interruption. I only wish I thought of doing this years ago.