I’ve decided to share her designs (her name has been blurred out for privacy reasons) alongside the email I sent her because the whole issue is a great case study in working with today’s available technology and not letting arbitrary ideas interfere with a website’s overall usability.

Here’s the homepage mockup she sent me:

Here’s the Portfolio page mockup she sent me:

Here’s “page 7″ which is referenced in the email below:

Here’s the website she used as her primary example:  http://two9design.com/two9wp/?page_id=13

OK, now here’s what we wrote rather than just “polishing” the design:

Hi *****,

I’ve been digesting these mockups and this sample site for a few days and was just sitting down to work on refining the design, but decided instead to bring up a few usability issues that have been vexing me.  I don’t want to just give the coders a site that’s going to be challenging to build properly and challenging for you to maintain properly.  Let me explain…

I completely understand your aesthetic preference for a wide aspect ratio.  The sample site you sent from twodesign LLC looks nice because of its austerity, but there are some problems with it from a functional standpoint:

First and foremost, we want you to have a WordPress Content Management System for your site so you can easily add to your portfolio and content.  But, when working with a fixed aspect ratio like this, you’re going to have issues when it comes to photo galleries and content.  Many times– and sooner than you think — your content is going to spill over and need more space.  This design will not allow that.  So there will come a time very early on where a content addition you make completely breaks your website’s design.

The design you’ve given me looks great as a print piece where every page is carefully controlled by the designer.  It could potentially work as a totally static website too, though you’d run into the limitations fairly soon that way too; but that goes out the window quickly when you have “dynamic content”, which is to say content that is inserted by you into a template-driven site wrapper.  That’s how website CMS’s work though.  For a CMS to accommodate your longterm needs, the layout has got to be flexible.  Vertically flexible.  With a content area that can expand to fit a variety of content types.

Doing so will accomplish several things:
(1)  Free up your content.  In some of your mockups, I can see that you were struggling to fit all of your content into the space that this aspect ratio allows.  Page 7 of your PDF, for example, feels quite cramped to me, and I’m sure you cut some content out too in order to fit it there.  We need to build you something that lets you put in the content you need to put in, no matter what that content is.

(2) Free up your navigation.  In the twodesign site, on the homepage “interior architecture | space planning” etc looks like navigation and probably should be, but it’s not.  That’s very confusing.  Then, when you navigate to an inner page, on some of them that area becomes navigation and on others it does not.  Very confusing to the user.  Rule #1 of website user interface design is Be Consistent, especially when it comes to navigation.  I know you’re attached to a vertical navigation like that, but it’s very limiting when it is placed into a fixed-size space.  You will run out of space.  I would suggest using a dropdown menu for your subnav, similar to the menus on this site:  http://www.fireeye.com/  – roll over “products and solutions” to see what I mean. In fact the FireEye site, while far too techy for you, does hint at a wide aspect while still accommodating content– the same way the Emerald City site, which you liked, does.  In fact, from a wireframe sandpoint those two sites are fairly similar.

(3) Provide negative space.  Leaving room for wider margins, clean paragraph spacing, empty space and nice typography provides a sense of psychological calm to the end user. When you have a fixed aspect ratio and have to find ways to cram your content into it, that sense of being cramped affects the end user’s experience in a negative way.  If you look at my site, www.iluminada.com , you’ll see that I’ve used the browser background for my imagery– it loads behind the content, giving me a wide aspect because that background fills the user’s browser frame entirely, no matter the screen size.  Doing so frees up a lot of content space so I can have nice, big fonts, plenty of breathing room and flexibility for different content types  AND you can click the little white minus sign at the content’s upper right to hide the content entirely and just see the image.  Calm and also cost-efficient to build and code.

(4) Free up your portfolio galleries.  You design some very nice, elegant homes.  I don’t want to see you cramming those beautiful photos into a small space.  WordPress will not easily accommodate this either.  WordPress gives you the option of doing a “slider” ( http://www.crockerhomes.com/ ) or a thumbnail grid: http://www.pricelandscapeservices.com/portfolio/ where you can click the photos to zoom in.  Taking advantage of this feature makes it FAR EASIER for you to effectively maintain your portfolio and for people to get to the photos they want to see.  They way you have it in your mockups won’t easily work with WordPress, if it can be made to work at all for the budget you have.

I hope I haven’t overwhelmed you here, but I felt it was important to raise these issues so you can end up with a website that’s both pleasing to look at and totally functional over the long haul.  Please take some time to digest this and, if you like, I can come up with a visual concept that strikes a compromise.

Thanks.

–JB

My client, whose site we built and now host, had purchased a new Droid smartphone and was having trouble getting his email setup properly on the phone.  He called the free 24/7 support line for his cell phone provider and had spent over 6 hours in 4 different calls talking to someone in India in the employ of a large cell phone service provider, without a resolution.  The cellphone provider (erroneously) insisted the problem was with his host, so by the time he got to us he was pretty frustrated.  This is common practice with outsourced support:  tell the client anything if it’ll get him/her off the line so you can fill your day’s ticket quota.

We were able to remedy his problem in 15 minutes once he called us.  But the call wasn’t free:  because we want skilled staff handling all manner of support issues, we have to charge our clients for support calls, even for websites that we host.  When someone calls us for support, a skilled local web developer addresses the issue, not a less-than minimum wage worker reading off a script.  This is the difference between paid support and free support.  Which would you prefer?  To lose 6 hours or to pay $42.50, the cost of our half-hour minimum charge?

Still, there’s more to this.  While we were able to help the person in this particular anecdote, your local web developer might not be able to answer every technological issue that comes in that’s outside of the web development realm.  While we make every effort to help our clients with all aspects of their web presence, we’re primarily designers and developers here– not cell phone support people.  In the case of the smart phone owner’s trouble ticket,  all we know is

1. Our mail server is set up in an industry-standard manner that should work well with any modern email client or smart phone;
2. Our mail server works well with the devices that we own;
3. Our server is monitored 24/7 by professional staff and there are no problems with the server at the moment;

We can’t be expected to know the intricacies of setting up every smart phone out there– that kind of thing is akin to calling your cable provider because your new TV won’t turn on.  We’ll try to help when asked, of course; but because we refuse to outsource our support and instead provide well-paid professionals for even the smallest support issues, these kinds of issues cannot be addressed free-of-charge… and some issues may still fall outside our area of expertise– we’re not God, we don’t know everything about everything.  But we have a lot of experience, and we will try hard, and we’ll give you honest and direct information that’s worth the nominal fees we have to charge for support.

Further, some would say “but my hosting company provides free support for email configuration, and it’s local and professional.”  I know that Cruzio does this, and it’s great.  They’re a good company, for sure.  But we provide totally different products.  Cruzio is a great shared host for many peoples’ needs.  They’re a hosting company.  We’re not.  We are developers.  Builders.  We host a handful of websites for our clients– sites we built and maintain for serious businesses because those websites run custom and sometimes resource-intensive applications– applications that our server is set up to run securely and quickly.  For reasons too numerous to count,  hosting these sites on our server saves development time… which saves our clients money.  Lots of money.  And when we’re going to be performing ongoing maintenance for a client, we want to have our regular version control system and development/staging environment setup– these things require a level of access permission and a software set that’s not available with most shared hosts.  By agreeing to be hosted on our private servers, our clients are acknowledging that we will be providing ongoing services for them, services that require the skills of a trained, experienced professional.  The only way we can afford to provide these services at the level our clients expect is to charge an honest rate for our time.  Still, in these cases, even when paying hourly for support, the cost savings during the website’s development and ongoing maintenance are immense.

Sometimes problems are not user error, however.  In either case, it requires patience and collaboration to get to the source of the problem.  I recently had a problem with a client that could have been easily avoided, and it seems like this is a good time to demonstrate the 2 ways this problem could have been dealt with:  first, how it actually went down;  second, how it should have gone down.  Here we go:

How It Went Down, a Dramatization

Client:
Some customers have called us complaining that the Widget you built for us last month doesn’t work.  I refuse to pay for something that doesn’t work.  Fix it now.

Me:
I’m sorry to hear that your widget isn’t working to your specs.  We’ve invested another hour into this and have tested it with Explorer 6, 7 and 8, Firefox, Chrome and Safari on Mac and Windows and can’t seem to duplicate the problem.  It has worked perfectly in every case, so it’s difficult to fix because we can’t seem to duplicate any problems with the information we have.  Can you provide us with some more information?  How, specifically, is it not working?  Have you tried it yourself?  Please try it yourself and let us know what the result is.   If you get an error, send us a screen shot.

(2 months of radio silence ensue)

Client:
The Widget you built us 3 months ago has never worked.  We refuse to pay for something that doesn’t work, and we refuse to pay for that extra hour you spent not finding anything wrong with it.  Fix it now.

Me:
As I said before, we need some more information about this in order to help out.  Try duplicating the problem yourself and let us know what happens, and send us a screen shot of the error.  Also try talking to the customer and see if you can find out what browser one of these people is using, what operating system and, if Explorer, what version and what level the security settings are at.  This is a very complicated Widget that makes your store software talk to Google Maps and then outputs all the content with javascript, so there are some links in the chain that can break and we need to know which link is breaking and whether it’s a link we have any control over.  At this point, we’re becoming unwilling to continue troubleshooting for you, since you’re refusing to pay for it and aren’t providing us with the information we need to effectively troubleshoot.

(1 month of radio silence ensues)

Client:
The Widget you built for us 4 months ago has never worked.  We’re moving on to another web person.  Why is it we always have trouble with our web people?  This happened the last time too.  I guess web people just suck.  And we refuse to pay for the Widget because it never worked.

How It Should Have Gone Down

Client:
Some customers have called to complain that the Widget you built for us isn’t working correctly.  I tried to duplicate the problem myself, and I can’t seem to do it– it seems to be working for me.  I’m using Firefox 3.6.7 on a Mac.  So I talked to one of the customers and sent them to www.supportdetails.com.  I’ve attached a screenshot of the customer’s operating system setup.  Turns out this person is running IE6 with javascript disabled.   The customer says he’s doing a search with your widget but gets a blank screen instead of results.   What can be done about this?

Me:
Nice detective work.  Unfortunately, your Widget is a modern web app and it requires javascript in order to show the Widget’s search results properly because they’re rendered with AJAX, which is how we’re able to show them so quickly without reloading the whole page.  Further, IE6 isn’t supported by most modern sites anymore, and the user base is only in the 5% range… but we’ve gone ahead and performed a temporary workaround for you by adding some simple detection features that warn the user about their browser, their need for javascript, and serve up a link to the free IE8 installer along with some instructions for turning on javascript (it’ll be on by default when they install IE8, btw).   That should buy some time while you think about this alternative:  we could write something that performs the detection and then outputs the results in a less-elegant manner that doesn’t rely on javascript if a user doesn’t have javascript enabled.  This would take a few hours, so I’d say it’s only worth it if this app is so crucial to your business that 5% of your end users being unable to use the Widget will impact your sales in a significant manner.  Just let us know how to proceed.

Client:
Excellent work, let’s leave it like you have it.  Thanks!

Summary

The second scenario is so much easier for everyone!  And it’s far better for the client’s business.  In a nutshell– running a website comes with some responsibilities.  You maximize your ROI when you take the time to learn how your website works and then use that knowledge to proactively interact with your customers and your web contractors.

Burnout is a huge problem in the hi-tech world, especially among web developers.  Because, for many of us, web development is a hobby as well as a job; and because of the 24/7 nature of the internet we tend to spend far too much time at a computer, which can result in an overall loss of productivity and creativity once the inevitable burnout sets in.  While myself and my staff are also somewhat guilty of this, I try to encourage a slightly more European approach to our schedule, with some unique twists.

As part of this outlook, I try to encourage time off for recharging– more than the typical 2 weeks/year that America has somehow erroneously (and arrogantly) adopted.  At the core of this is my desire that myself and my team be the best at what we do.  Not just average or good enough, but the best.  In order to be the best, most creative and most efficient designers and developers, we need to be happy, rested, balanced and focused.  Otherwise it would be far too easy to turn into that grumpy, no-life IT guy we’ve all heard of and/or dealt with.  No one wants to deal with that guy.  Apart from encouraging after-lunch siestas, the taking of “sanity days” off, beach and/or garden breaks and the occasional Tequila Friday at the office,  I achieve this balance by taking sanity time– surfing, snowboarding, gardening, traveling, spending time with family, making wine and… well… once every 4 years dropping everything for the World Cup.  I also encourage my staff to do the same.  I am a HUGE national team soccer fan.  Men’s and women’s national teams.

Yes, iluminada design is a great place to work.  But only if you’re interested in being the best and doing what you have to do to be the best, both professionally and personally.

Today, 6/11/10 marks the start of 1 month of World Cup Soccer.  Fortunately, most of the games occur early this year– before we open for business at 10:00am.  But, for the record:  don’t be surprised or upset if the phone lines go to voicemail during (1) every US match (there will probably be only 3 of them because we suck this year) and (2) every Brazil match (we have some close Brazilian friends and colleagues).  There will probably be lots of Brazil matches– they’re awesome and are my bet to win it.

No need to worry– we won’t be abandoning our friends and clients for a month.  We just might get started a bit later than usual on a few days.

Similarly, I believe it is absolutely necessary to observe certain holidays.  MLK day is not an optional holiday.  It’s the one mandatory holiday here, ahead of Christmas and New Year’s day (which we observe each year by closing for a week).  I couldn’t give a rat’s ass about Columbus Day,  but I do care about and observe Memorial Day and Veteran’s Day.  I also think everyone should always take their birthday off if possible.  And Bob Marley’s birthday too, though no one knows exactly what day that is… so any day in early February will have to do.  So please don’t be upset with us when you find us closed for holidays:  we’re trying to introduce a measure of humanity to the hi-tech industry, and I hope you can respect that.

Make sure you’re running Safari to check out the demos on the site below:

http://www.apple.com/html5/

The sooner all of you stop using Internet Explorer and move to standards-compliant browsers like Safari, Firefox and Chrome, the sooner we will be able to grow the web into a new realm of possibilities.

www.happymagicfuntime.com/blog/entry/html5_for_drunks

www.webdesignerwall.com/demo/css-buttons.html

Here’s the article.

http://www.phparch.com/2010/02/19/php-architect-podcast-oddweek-003/