BKWLD

Archive for June, 2008

Why We Scrutinize Every Detail In Photoshop Before Going To Build

By Mark on June 23, 2008 at 12:06 pm

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.

Kanye pretty much rules the world.

By Jennie on June 16, 2008 at 3:16 pm

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.


img_0329.JPG
Kanye takes the stage

How to refresh listeners in Prototype

By Garrett on June 15, 2008 at 12:11 am

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.

Styling List Items Seperately

By Garrett on June 13, 2008 at 8:11 pm

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;
		}

Flex and SVN

By Robert on June 5, 2008 at 9:25 am

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.

How Robert does Email

By Robert on June 1, 2008 at 2:57 pm

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:

picture-2.png

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:

My inbox

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.