(via Signal vs Noise)

I love seeing how other designers present information and ideas in a easy to digest format.

Visual design is often subjective and can be difficult to describe or judge. Often, people lack the language or understanding of the work to accurately express their opinions. Consequently, we use simple terms of the way an object “looks” or how it “feels”.

Speaking in terms of these qualities does a disservice to the design. We cheapen the value of the work by paying attention only to the superficial aspects.

When I refer to the visual design of a website or a web application, I tend to use “aesthetics” or “style layer” but those words don’t do visual design any more justice than “look and feel”.

Also, don’t forget to read the comments.

I recently began working with a client whose staff doesn’t design together. When they walk into the office in the morning, they plug in their headphones and stare at their screens, hardly speak to each other, and forge product plans by way of short, infrequent conversations about what needs to be implemented next and when. The conference room has only a table and a projector. The front room is filled with broken-down boxes, presumably leftover from setting up shop in a new place, but the company has been in the space for months.

The people on this team are smart and engaged, but they’re nowhere near doing their best work. They’re not taking advantage of each other’s ideas and passions. They’re not having any fun.

I’ve worked in a couple of environments similar to what Robert describes here. In both environments, I did not work at an efficiency I would consider to be productive. More importantly, I did not produce what I would consider to be my best work.

What I’ve taken away from both experiences is the work environment of any job will always set a threshold on the potential enthusiasm (and fun) you will have for the duration of your time at said job. In other words, focus on evaluating the team you will be working with, not the work you will be doing. Enthusiasm and attitude is contagious.

A bit of a tangential thought from Hoekman’s point, but thought it was worth noting.

Brief Overview of the HSB color space

Before we choose the monochromatic color palette, we need to understand what HSB is. HSB is a color space that defines colors based on 3 values: Hue, Saturation, and Brightness¹. Imagine HSB as a cylinder: Hue takes a value of 0-360°, saturation and brightness each take a value of 0-100%. In my opinion, the last 2 values is what makes HSB so wonderful to work with, as I can adjust colors by changing these values without using Photoshop as a intermediary. This is why I prefer HSB to using RGB. It’s far less abstract and lends itself to how humans perceive color.

Choosing the colors

When I started choosing colors for version 4 of chrisgriffin.org, I began with a dark base color since I was going with a light on dark theme. I ended up choosing a slightly warm dark gray. In HSB, it’s value is (60,8,14) (the hex value would be #242421). The rest of the grays in my design are a variant of this base color. The way I did this is just by increasing or decreasing the brightness value in increments of 10 (and sometimes 5). For example, the background color of the main navigation here is (60,8,34), compared with my base color, there is a 20 unit brightness increase. Obviously, you can choose intervals that work best for your design. Adjusting color saturation is just as easy; let’s say I wanted a slightly less saturated color for my visited links, I would decrease the saturation value depending on how unsaturated I would like the color to be.

HSL and CSS3

The CSS3 color module includes the HSL color space which will allow for easier color adjustments without the need to fire up Photoshop. At the time of this writing, the major browsers that have HSL support are Firefox 3, Safari 4, and Opera 9.64. Since CSS support for HSB is not supported by IE (big surprise), it’s best we continue to use hex values in our CSS, which means you’ll need to use the hex value that the Photoshop color picker generated when you chose the color palette using HSB.

More Resources

• Wikipedia: HSV Color Space
• W3C: CSS3 Color Module
• Working with HSL in CSS

1. HSV, HSL, and HSI, are other color spaces that use a very similar representation, but for the sake of this tutorial we’ll stick to HSB because that’s what Photoshop uses

Enter Deadbolt. I’ve owned this domain name for just over 3 years with the intentions to rebrand myself, and with my current situation, I decided it was time to do just that. Griffin Webworks is now officially retired.

And with that, I’m open for business.

Sometimes I wonder, then: given that everyone in design seems to more or less know everyone else, are we really having the kinds of meaningful, constructive, critical discourses that we really should be having? Are we too quick to take offense at the opinions of our peers? Or are we pulling our punches too much when discussing the merits of the work that our peers turn out? To put a finer point on it: are we being honest with one another?

When someone asks me for feedback of their work, I try to be objective and honest with them, even more so when I have a certain level of rapport with said person. But, when I have something critical to say, I watch my tone of voice, as I want them to hear the feedback without the person interpreting as a personal attack. My experience with designers (myself included) is they sometimes align critical feedback of their work with a personal attack.

Personally, I like to think I take criticism well from designers who I respect. The trouble I have is a tendency to dismiss feedback from designers who I don’t respect, along with non-designers, non-designers commonly being developers. Their reputation (or lack thereof) precedes their feedback and holds less weight with me, even if they have valid concerns. When I step back, I see that I should handle these situations more objectively by being more inclusive and receptive, while remaining assertive, standing behind my design decisions. Clear communication and approach is key here, as we all have our egos to worry about.

Why the new domain?

Honestly, I never liked having my middle initial in my domain name, but being that Chris Griffin is a somewhat common and famous name, I had to settle for Chris Z. Griffin when I initially bought the domain in 2005. Sounds picky, I know, but I always thought it sounded out of place with my nickname, Chris, as middle initials are usually reserved for more formal purposes. So, you could imagine how giddy I was when I stumbled upon chrisgriffin.org while purchasing chrisgriffin.me last July, only 16 days in the wild after it’s previous owner abandoned it. When I moved to a new host I decided to go ahead and switch domains.

Boxcar

Beginning of this year, when I decided I wanted to move from the shared hosting environment I had over at Media Temple to a VPS, I decided to go with Boxcar. Beyond the fact that as an employee of Planet Argon, I get a free Boxcar, not to mention that if at any time I’m having any problems with my hosting I could literally throw my shoe at Alex’s head. But seriously, I hear nothing but good things about it from Boxcar clients and our managed hosting clients. And yes, I’m a little bias.

Wordpress

if that wasn’t enough, I decided that it was time to abandon the abondonware blogging application Simplelog. In my last post, I stated that I wanted a blogging application that ran on ruby on rails so I could get my hands dirty in ruby. That still stands true, but I came to the realization later that I just wanted a place, first and foremost, where I can just write. Writing and refactoring code should come secondary to that.

Enter Wordpress. I know it’s PHP, it’s bloated, and a bit ugly, but it has a decent UI, almost everything I needed in functionality, and what it lacked in functionality, there was bound to be a plugin to fill in the gaps. I won’t go into any more details about Wordpress, as it’s ubiquitous on the web and the upsides and downsides are well documented.

New Design

And lastly, the redesign. This redesign was a bit spontaneous, as my original plan was to migrate the old design to Wordpress and revisit the design later. Just as soon as the old design was completely migrated, the redesign bug hit, and I decided to go ahead with it. Migrating the old design first actually worked out for the better, as that was my first experience working with Wordpress and it’s template system. The second time around, I had more of a grasp as to what I was doing.

With version 4, I decided to do something I’ve never done: light on dark. I’ve tried it a couple times in the past, but I ended usually trashing it, as the dark design never felt right. This time around, I went with it and never looked back. I got through the design phase in about a week and a half of my spare time, which was pretty quick considering there were times I’ve spent month(s) on a design.

For the grid CSS framework, I rolled my own. It’s based off of 960 Grid System but I wanted to create something from scratch, as there were things I didn’t need in 960 GS. What I came out with was something similar to the 960, but with two major differences:

• No IE6 support: I like writing as efficient CSS as possible (as most developers do), and since I am not supporting IE6 in any way, this opens the door to a plethora of options for selectors and properties that most of us designers and front-end developers dream of using, but tend to avoid because it’s not supported by IE6, such as :first-child and :last-child and the selectors that include class subsets (e.g. .main.link).

• Less bloat: When CSS frameworks provide options to accommodate different grid systems, or better yet, all in one solutions such as typography styles, icons, etc, such as Blueprint provides, it also comes with extra baggage. This isn’t a knock against 960, Blueprint or any other CSS framework, as these are built for a lower common denominator than what I needed, and for different uses such as prototyping.

Handy Wordpress Plugins

In addition to blog entries, I wanted to have a place where I can also post interesting links with commentary. Wordpress, plus the very simple wordpress linked list plugin allowed for me to go with a different format for this version of my blog. You will see blog entries and links in similar fashion, and both will appear together in the RSS feed. I have plans to also include blog entries only and links only RSS feed, but for now this should work just fine.

The archives page is probably the page I’m most proud of. I didn’t want a typical archive that lists out years, months, or categories in a typical, not very useful format. I went digging around for a wordpress plugin that allowed me to display months by year. I found one that allowed me to do just that called Smart Archives Reloaded. I had to completely rewrite the HTML output, but the final result is exactly what I wanted. As for the category list by alphabetical order, I had to use Multi Column Category List. Again, this plugin required me to change almost all of the HTML output.

Conclusion

So there you have it. I think, for once, I’m completely satisfied with the my blog setup and design, and who knows, I may write a blog post or two. Feel free to leave feedback via comments or the contact form.

Also read Website Optimization’s for implementation methods.

At Planet Argon, we’ve been using 960 Grid System in most of our projects for the last few months. Some of our internal projects, we’ve been using a heavily-modded version of 960 (more on that later).

(via Jeff Croft)

It’s been happening throughout history, of course. Beautiful accidents. Unintentional intentions. We can’t plan these mistakes, but wish we could. What seems like disaster, turns into the spark that ignites what we perceive later as “rightly so”.

And it happens all the time when I’m designing. Oops, I dumped a white paint can where color used to be. Wait. That’s nice. It’s become a part of my process. A part I can’t anticipate, or account for, but a part nonetheless.

The serendipitous nature of design is part of what makes it so rewarding—those eureka moments.

Maybe I’m still hanging out in the web standards design blogosphere too much, but finding IxD & IA blogs to read have been few and far between. The ones I have found get updated once every 8 months or so. In an effort to spread the knowledge, here are some initial thoughts and experiences from an IxD n00b:

• Designing for interaction requires a lot more thought – Seems like an obvious assertion. Creating an user experience with interaction and behaviors that users have to interact with on a computer is a daunting task. In visual design, design decisions are based on an emotional response. Visual design for web applications—most of the thinking is already done for you.
• The sketchbook is your friend – Until recently, I didn’t do much sketching. I had nothing against it—it was a personal preference. After doing some sketching for a current project, I have found it useful in getting solutions & ideas out of my head quickly and with little effort.
• Wireframes versus HTML Wireframes & Prototyping – I am a big proponent of HTML wireframing & prototyping. Web applications encompass a lot of different interactions, some simple, some not so simple. Asking a client to fully understand a paper document made up of interface elements and interactions is asking too much. Paper is an inherently static medium, which is counterintuitive to the point of having wireframes in the first place. On the other hand, HTML wireframes & prototyping can capture interactions exactly same way as the will be in the final product. The design document is actually the final product. This topic is a blog post in itself, so I’ll leave it at that.
• OmniGraffle is the worst (wireframing) tool ever – I’ve been taking my OmniGraffle rants out on twitter for the last couple of weeks. I really don’t understand why people love OmniGraffle so much. Maybe Photoshop spoiled me with all the keyboard shortcuts, but I’ll be damned if I have to use the mouse for everything. Having “hot keys” for the tools is ridiculous. Not only that, OmniGraffle seems to have a problem nudging things around when nobody is looking. I’ve went to other pages and come back to see elements nudged over 1px. I’d use OmniGraffle for flowcharts and diagrams, but anything interface related? most definitely not.

Overall, I really enjoy what interaction design & information architecture has to offer. It may not be something I ever master, but putting my brain to work to turn client ideas and business goals into something real that people can use is something I can get passionate about.

Over the past 7 months, I’ve learned a considerable amount from the developers, and gasp, it’s not all that difficult.

Here’s the 4 things that every designer should know when working with developers:

1. Command Line: Otherwise known as Bash on OS X/Unix. Before I started at PA, my thoughts were “Why the hell do I need the command line when I can do all the same things through the GUI, silly developers always making things so complicated!” I was totally wrong, the command line seems daunting at first for a n00b designer, but after learning some basic commands, it makes a lot of simple tasks (such as creating/moving/renaming directories) so much easier. Not only that, it is probably the most used tool that developers use.

2. Subversion: After learning some basic Bash commands, the next step was learning about Subversion and all its goodness. Version control is an essential for team of developers, or even if you are a freelance. As a designer, I’ve only had to learn a handful of svn commands (svn co, svn up, svn ci, svn st to name a few). There’s also a textmate bundle for the faint of heart. There’s really no excuse a designer can give to learn a few simple commands.

3. HTML & CSS: This one seems a bit obvious, but believe it or not, there are actually web designers out there that are still clueless when it comes to HTML & CSS. Most of these designers are “converts” from the print world and I use convert loosely because if these so called web designers don’t know HTML and CSS then they are not web designers–they are hacks. Designers can not design for the web if they do not know the limitations of the web, and there’s no way to know the limitations unless you know the fundamentals of the web.

4. Ruby on Rails or your preferred programming language: If you are a designer that learned how to develop, then you have came full circle. You are one of the few that have mastered both disciplines in two different spectrums of the web industry. I applaud you.

What else do you think designers should be required to learn before/while working with a development team?