Blog . Adam Bard

Please use tabs in your designs.  Tabs are a very conventional navigation technique, and are fast becoming a staple of the non-web app experience.  I bet your browser has them.  In fact, if it doesn’t you should immediately stop reading and go get firefox. IE6 is the bane of my and every other designers’ existance, and should be burned with fire.

Back to tabs.  Everyone is using tabs these days, and for good reason.  They are one of the most intuitive interface elements, and they’re easy to do.  Even the new Microsoft Word 2007 uses tabs for its user interface, and they poured thousands of dollars into usability testing and revamped an already well-understood and canonical interface to implement them.  How’s that for an endorsement?

Rules for Tabs

In his article Tabs, Used Right, usability maven Jakob Nielsen outlines 13 rules for proper tabs.  I, however, happen to think that some of these rules are a bit draconian, and others are a bit obvious, so I’ve come up with 4 simpler ones.

1. The scope of the tabs’ influence must be clearly delineated.  If the tabs change only the left column, the left column should be in a little box with tabs on top.

2. The current or active tab must be connected to the content, and have a higher visual weight than the inactive tabs (higher contrast, brighter saturation, etc.)

3. The labels for each tab must be sufficiently short.

4. The tabs must stay on one line, as long as the text is at  a reasonable size.  Don’t cheat and make the text smaller — make fewer tabs required instead.

As long as you keep this in mind, you can’t screw things up too badly.

Resources

I was planning to do a roundup here, but it turns out that Smashing Magazine has me beat. Go there if you need some tab help.  And, if that’s not enough for you, here are 10 more for AJAX applications specifically.

I recommend avoiding Javascript as far as is possible for your tabs, as I do for all applications.  You’ll probably be able to do everything with css except in the case of IE6, and I think people using IE6 with javascript disabled are too far-gone to be helped.

According to the date that his second-most recent article was Dugg, Samuel Ryan’s Wake Up Later has been dormant for 100 days.  His most recent post is one entitled, ironically, Falling Behind is Not an Option.

However, if the subscriber count displayed on his homepage is to be believed, he has lost few subscribers over this time.  I myself was notified of his triumphant, and hopefully lasting, return by my own feed reader registering a new article.

Write Smarter, Not More

Your feed subscribers are your most loyal readers, in theory — so thanks to the 3 people and 9 robots who subscribe to this blog.  With this in mind, one can infer that the penalty for falling behind is not a severe one.  In fact, in recent memory, I cannot recall removing a single feed from my list due to inactivity.  Most are removed because their articles are too frequent and too crap.

I subscribe to way too many feeds, and except for the ones in the “funny” folder, I hate when they update several times each day.  I just can’t keep up with that, and there’s no way that each of those postings is necessary information.

Serve Your Audience

The legendary Jakob Neilsen has long advocated that people Write Articles, not Blog Postings.  The way to popularity is to foster those return visits from people that value your informed expertise, not your fickle opinion.

Write posts catered to the consumers of this expertise.  Don’t clog your blog talking about some movie you saw, or your vendetta against auto-flushing toilets, or frustrated rants about CSS and Javascript. It won’t win you any readers, trust me.

Stick to your guns and write what you know, and only about what you know, and you’ll go probably go far.  Don’t worry about keeping the front page fresh if you have nothing fresh to fill it with.

I’ve gone and downloaded the newest GIMP, 2.6, and while I wasn’t disappointed, per se, I didn’t all that much new with it.  Certainly there were some slight improvements to existing tools, although they’ve gone and broken my standby way of deselecting things with their new polygonal lasso.

But, there is one change that for me is reason enough to have upgraded and then some, and that is the improvements to the text tool.  I use GIMP to lay out websites, you see, and for some time the lack of support for resizable text boxes has been a big pain.  It’s really annoying to have to insert your own line breaks every time you resize something.  But, with that cured, I can finally say that I have no major qualms with GIMP.

Except, that is, the continued inability to group layers together and manipulate them as a group.  That’s really annoying.

You don’t need me to tell you that mobile internet devices are becoming increasingly popular.  Hell, even my phone can be used to check email and read my Google reader, and it’s a few years old in design.

However, I find myself more or less restricted to Google’s websites, since they’ve done a very good job of creating mobile versions of their apps, which are usable even on my 1.25×1.5″ screen.  Other sites are too much of a pain to bother with.

I’m not talking about things like the iPhone here; they’ve been specifically designed to make the web usable in its existing state.  I’m more talking about phones that we regular (i.e. thrifty (i.e. poor)) folk have.

Here are a few guidelines to follow for mobile sites.

Content on Top

Aside from an <h1> and/or small logo at the top, you should put body content first.  Mobile phone browsers are much more likely to want what’s on that exact page, especially if this QR Code business ever catches on here.  (Incidentally, if anyone is interested you can get a QR Code sticker for your business from Evocode.)

After your content, you can put your navigation links.  More on that later.

Keep Content Focused

Eschew surplusage. Writing for the web demands you be succinct, and for mobile devices this need for information density is amplified.

Use Keypad Navigation

The little-known accesskey attribute may be placed on links, simplifying navigation.  Make this a number, and most phones will accept a keypad press as a click on that link, e.g. <a href=”#” accesskey=”1″>.  Just be sure to mention the number before the link so the user knows to press the button.

CSS: Keep the Colors, Ditch the Rest

Don’t try to get fancy with positioning, or fonts, or layout.  The best thing that can happen is that the phone will ignore you; the worst is that the phone actually tries to create a column and ruins everything.  Fonts will almost certainly not be recognized.

However, as long as you ensure sufficient contrast, colors are perfectly acceptable.  Even a small gradient background image, if you like.

To Serve a Different Page, or to Use CSS?

If you already have links at the bottom of your page, you can simply use a different stylesheet to hide elements that you don’t need, using <link … media=”handheld”>.

However, if you don’t have links at the bottom, or if you need a more thorough way, you can use a detection script to determine whether the browser is a mobile one, and serve different pages or versions accordingly.  On design.adambard.com, I’ve simply overloaded the header and footer for the mobile versions to display less information, leaving the content untouched(although I could definitely stand to tighten up the writing).

Another method is to use a different domain/subdomain/url, which serves your mobile content instead of the traditional content.  This is the most thorough method, since it can avoid issues with mistaken detection.

More Resources

Here is a device-detection script in PHP.  You can use this to serve different pages to mobile or pc clients.

Here’s a mobile phone emulator.

Here’s a sitepoint article with more on this subject.

I’ve decided to abolish hourly-rate quotes for all my projects, or at the very least make a concerted effort to.  It’s a good way to ensure that I get paid for my work, but I think the benefits outweigh this. Here are a few reasons why:

Higher Quality

When you have 20 hours to fill, and you finish the project in 10 (which happened to me TWICE last month), if you’re billing by the hour it’s hard to justify putting the other 10 in to relatively minor changes.  However, if you’re a classy guy like me and you choose to deliver quality work, you are welcome to spend the other 10 hours polishing and generally turning a good site into a great one.  This, rather than being inexpensive, is what you want to be known and remembered for.

Harder Estimates

While I do think it helps business relations when I come in a few hours under my estimate, it’s not worth the risk of overshooting.  Plus, this way you can collect a proper 50% up front - which you should always always do no matter who you are.

No Pressure

Sometimes I sit down, and even though I have a few moments to spare I feel I can’t work on a project because it’ll only be 15 minutes.  When everything is progress-based, pressure is alleviated.  I can work on it when I want, and it’s done when it’s done.

No Tracking Time

Although I do have this product Tasksy that’s built around tracking time spent working and then invoicing it, I must admit that it’s a bit of effort.  Happily, Tasksy can be used to bill by project too, and it’s always good to keep track of how much time you’re spending, both for your and your clients’ benefit.

No More Outsmarting Yourself

Have you ever had a stroke of genius, and accomplished in a few minutes something you thought would take an hour?  It happens to me slightly more often than the inverse, which means that I tend to overestimate.  Plus, it sort of takes the piss out of doing something really clever to realize that you’ve just cheated yourself out of income.

I admit it’s harder to sell people on $x hundred dollars flat, rather than $x per hour.  But, it will be worth it in the long term. I hope.

Links

Here’s a post on deciding when to use project pricing, from wakeuplater.com.  Unfortunately, poor Samual Ryan is either overworked or dead, so the blog is defunct.