Chris Z. Griffin

Finally

cgriffin@griffinwebworks.com (Chris Griffin) — Mon, 07 Apr 2008 14:49:00 GMT

Hi blog readers. If you haven’t already, click on through to the site. You’ll see some changes, I promise.

So I’ve redesigned, finally. I promised myself I wouldn’t tell a long story of the trials and tribulations of how I came to this design. Just know that I actually started doing some IA work on it about a year ago and then it dropped off the radar for about a year, and picked it back up in February of this year.

The goal here was to keep it fairly simple. I wanted the content to stand out and come first. Frankly, I’ve never been a fan of the heavily styled blogs. While they are “pretty”, there is a threshold where a blog loses its utility and becomes more of a piece of art. For some, I guess that is the point, but to each his own.

Right now, it’s a bit rough around the edges. I have a long list of known issues that I put off because I felt were not show stoppers like:

It doesn’t look great in IE6. I’m debating whether I’ll even attempt to dumb down my markup and CSS for the inferior browser.
HTML may not validate, if you care about such trivial things.
Search doesn’t work. I have a whopping 13 posts, so I think you’ll live. If that’s not good enough, here’s Google.
Tidying and refactoring of some of the code.

Why Simplelog?

I wanted to stick with a blog application that ran on ruby on rails. My reason is twofold: As a rails noob, I wanted something I could hack on and get my hands dirty, and even though Simplelog development has stagnated as of late, I still felt the UI is simpler and has less cruft than Mephisto, which seems to be the ruby on rails blog application front-runner.

Thanks

Thanks to Robby Russell for the help on all the random development and deployment issues I was having, and to Andy Delcambre for helping me getting this beast up and running.

Blog Resuscitation

cgriffin@griffinwebworks.com (Chris Griffin) — Tue, 04 Mar 2008 14:03:00 GMT

So I haven’t written a damn thing in 6 months. Why? I don’t have much to offer for an actual legitimate reason, but I do have plenty of excuses. As for the excuse, I would have to go with laziness and not having the “blogging itch”.

I decided I really needed to make more of an effort here on my personal blog, as it reflects poorly on me from the lack of writing to the default template that has been up for a year, a. year. That’s sad, even sadder that I call myself a designer. Saying that, I’m going to start making big changes around here.

Change #1: Say Bye Bye to the Default Template

In the very near future (by very near future, I means an ambiguous day in the realm of the very near future that isn’t specific enough to be held accountable for if I do not meet the goal.) this blog will feature an awesome new design by yours truly. Right now, I’m working on beating Simplelog into submission (a few nit-picky things), which is tall order of rails development for a designer. There also needs to be a few more lines of HTML/CSS to be written here and there. So, get your validators ready.

Change #2: More Linkage

My first and second attempt at blogging were more about coming up with original content. If you can do this on a regular basis, hats off to you. I, on the other hand, have trouble doing this—especially since this blog is not my full-time job. To keep things moving, I’m going to start posting links with commentary inline with the posts. This is an experiment to keep this blog interesting between blog posts. I will start doing this after getting the new design up, as this may require some development work.

Here’s to hoping that I won’t fail my blog a third time around.

Less Mouse & More Keyboard

cgriffin@griffinwebworks.com (Chris Griffin) — Tue, 21 Aug 2007 17:39:00 GMT

I’ve started to re-think my use of the mouse as an input device. The mouse is an inherently slow, unproductive tool for tasks that do not require precision. Yet, we use the mouse for these tasks because it is a habit left over from our computer beginner days. Think about it, the mouse only took a matter of 5 seconds to figure out. But since we are computer experts now, why do we use a mouse when using a keyboard shortcut could do the same thing quicker?

I always love when I find a keyboard shortcut alternative to mouse clicking. It means just a little less strain on my right wrist, which at the ripe old age of 24, is starting to feel a little bit of a tingle from the 10 years of mouse wear and tear. It also means I don’t need to use the dreaded mighty mouse (the only Apple product that I hate).

I’ve recently discovered a few very handy text editing shortcuts in OS X that have cut my “mouse time” down dramatically. All of these keyboard shortcuts move the cursor using a combination of COMMAND, CONTROL and the LEFT & RIGHT ARROW keys:

NOTE: If the SHIFT key is pressed with any of these shortcuts, it will highlight text from the current cursor position to where the cursor was moved.

Action	Shortcut
Move cursor to beginning/end of an area of text	COMMAND + ↑ / ↓
Move cursor to the beginning/end of a line	CONTROL + ← / →
Move cursor to beginning/end of a paragraph / block of text	OPTION + ↑ / ↓
Move cursor to beginning of next/previous word	OPTION + ← / →

After finding about these simple shortcuts, I wonder how I didn’t know about these earlier.

2 of my favorite shortcuts in Textmate for for code editing are:

Action	Shortcut
Move selected text	(With text already highlighted) CONTROL + COMMAND ↑ ↓ ← →
Block Code Commenting	(WIth text already highlighted) OPTION + COMMAND + /

I spend a lot of time in stylesheets, so I make use of the block code commenting keyboard shortcut when I’m troubleshooting CSS.

There are a ton more shortcuts I didn’t mention here that I use. For more keyboard shortcut goodness:

What are your favorite shortcuts?

Transition from Visual Design to Interaction Design

cgriffin@griffinwebworks.com (Chris Griffin) — Tue, 14 Aug 2007 18:00:00 GMT

Over the past month at Planet Argon, I’ve been taking on more interaction design work. Mostly because there’s a gap to be filled with all the design work on our plate, but also because I said I was willing to take it on. Visual design to interaction design doesn’t seem like a huge transition on the surface (it’s all design right?), but it has really been a challenge.

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.

Killing Spam & IMAP Your Gmail

cgriffin@griffinwebworks.com (Chris Griffin) — Sun, 12 Aug 2007 13:20:00 GMT

Killing Spam

My Griffin Webworks email has been riddled with spam for years. Long ago, I exposed my email to the web with my first incarnation of Griffin Webworks, and spam started rolling in after a few months. My web host for Griffin Webworks, Media Temple, has a spam filter called Mail-Protect, which is decent, but not as good as Gmail’s spam filter.

My personal Gmail account sees much less spam. It has mostly to do with the fact that I keep it private, and that Gmail has a great spam filter. So to get rid of my GW spam, I decided to route my GW account through a Gmail account to see what effect it would have on filtering out the spam. I went from about 20 spam emails a day to about 1 spam email a day.

It’s very simple what I did, and anybody with any technical expertise probably already has this set up, or has some other method of filtering their spam. I’ll run through the steps on how I did this:

Create a new “branded” (aka #######@griffinwebworks.com) email, and a new Gmail account just for spam filtering.
Set up my public-facing branded email to forward to the Gmail account I just created.
Set up Gmail to forward to the new branded email I created in step 1
In Mail.app (or your favorite email client), change your account to use your public-facing email as the reply-to email.

Now your branded email will run through Gmail’s wonderful spam filter and then forward to a private account.

IMAP your Gmail

UPDATE 10/23/07: looks like Google finally released IMAP for Gmail, which renders this tutorial meaningless.

One annoying thing about Gmail is their lack of support for IMAP. Using Gmail via POP isn’t so bad when you only have one computer (as I did). Now that I have an iPhone, I had duplicate emails coming into 2 email clients. Ironically, to solve this problem I had to do the opposite of what I did above to kill my spam:

Set up a new email with IMAP capabilities (in this case, a new Griffin Webworks email).
Forward my Gmail to the email I created in step 1
Set up the IMAP account in Mail.app (or your favorite email client) using your Gmail as the reply-to email. I did this by setting up Gmail as the outgoing server.

My Griffin Webworks email is virtually spam free, and my Gmail account has IMAP capabilities.

Also see: Spam Free Email (For The iPhone) by Sean Sperte

RubyURL: Keep it Short (and Sweet)

cgriffin@griffinwebworks.com (Chris Griffin) — Sun, 12 Aug 2007 10:45:00 GMT

I’m a few days late announcing this, but Wednesday, Robby launched the new version of RubyURL, the first rails application running on Planet Argon’s new hosting platform, Boxcar.

Robby did all the development work for RubyURL, and I was in charge of the visual design & XHTML/CSS. Not to be too self-indulgent, but this has to be the sexiest URL “shortner” on the web right now. Not too bold of a statement when you take a look around the web (if only sexy accounted for something :) ).

If you find any bugs, feedback or feature requests, feel free to post them here.

Give Me the Real Internet, Not the Mobile Internet

cgriffin@griffinwebworks.com (Chris Griffin) — Wed, 25 Jul 2007 15:29:00 GMT

One of the killer features of the iPhone is I’m fully capable to see the internet in its truest form. MobileSafari has absolutely no problem rendering HTML & CSS, as it renders it exactly the same as it would if I were using Safari on OS X.

We are all in agreement here, right?

So why are websites forcing me to use their mobile-friendly version of their website? (Amazon and Bank of America, I’m looking at you).

It’s true that the majority of iPhone users may prefer the mobile-friendly version of a website. My point is, my iPhone is capable of seeing the “real” internet without any extra effort on behalf of these companies. So, let it be my choice. Give me the option to switch to a mobile version if I so desire.

Let me decide how I want to experience your website on my iPhone, whether it be the “real” way or the mobile way.

Thoughts on iPhone

cgriffin@griffinwebworks.com (Chris Griffin) — Tue, 17 Jul 2007 14:37:00 GMT

As if you need to read another blog post on the iPhone right?

When the first iPhones started rolling out at the end of June, I had no plans to get one right away. After all, I was a Verizon customer still under contract, so not only would I have to pay a hefty $600 for the iPhone itself, I would have to fork out $175 to cancel my Verizon contract. I’d thought I’d wait to hear what problems the early adopters a.k.a. “beta testers” would have with the highly coveted super gadget.

Every 5 minutes I would get a twitter update about how great the iPhone is at this or that.

“Blah blah blah,” I said.

I still had myself convinced not to get one…that was until I held one in my hands. 2 weeks later, I broke down and bought one.

So after playing with it a few days, here is my mini-review of the iPhone:

Things I like:

Activation was incredibly easy, and there was no “setting up” the iPhone, Address Book, iCal, and Mail synced with the iPhone and I was good to go.
The user interface is incredibly solid for a 1st gen phone. There’s not much of a learning curve if you are a mac user or any user for that matter.
The touch screen is very bright and shines right through all fingerprints
For how small the screen is, I’ve had no major problems with browsing the internet. Zooming in and out, and scrolling side to side with your finger is so much easier than with a mouse.
After a couple days, I could type faster on the on-screen keyboard than I could on a phone keypad.
iPhone software updates will come directly from Apple via iTunes. Improvements will come in increments.

Things I Don’t Like:

No iChat—obviously a business decision as there wouldn’t be much use for text messaging anymore.
No Feedreader—Yea, I can use Google Reader, but I use RSS for as many things as I possibly can, and you can’t reach password authenticated feeds with google reader.

Obviously the good things by far outweigh my small quibbles. The iPhone is very solid for a first gen device, and it’s only going to get better with time.

Designer/Developer Synergy

cgriffin@griffinwebworks.com (Chris Griffin) — Thu, 21 Jun 2007 16:15:00 GMT

Before working at Planet Argon, I’ve never worked for a company that was made up of mostly developers. At the beginning, I wasn’t sure how I would fit in being that my skillset had very little overlap with my newly-acquainted comrades. Not a huge deal considering I’m a designer and I wasn’t necessarily hired to know these things, but I felt it was my duty to at least make an attempt to learn.

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:

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.
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.
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.
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?

Boxcar

cgriffin@griffinwebworks.com (Chris Griffin) — Tue, 08 May 2007 11:16:00 GMT

Today, Planet Argon announced a new business hosting plan called Boxcar. If you are looking for hosting for your rails application in the coming weeks, and need a bit more power than what a shared server has to offer, look no further.

Head over to the Boxcar website to sign up for the mailing list and you will be notified as soon as Boxcar launches.

On another note, I believe this is the first of my design work I’ve done since I was hired that has seen the light of day….BOO YA!