Blog.adambard.com

If I had six hours to chop down a tree, I’d spend the first four hours sharpening the axe.

That well-said piece of wisdom comes from Abe Lincoln himself. I can’t recall anything that Lincoln did which illustrates this particularly well; he doesn’t come up in history class much here in Canada. But, that doesn’t mean this isn’t very good advice.

When you plan out your projects, you will write fewer bugs when you know what you’re doing and how you’re doing it. Your pages will be tighter. Your prose will be better, and your ideas more concise. Plus, you won’t be tearing your hair out tracking down those bugs and extra words. Although for page layouts, it might have been better of Abe had ended his quotation with the words, “Also, fuck IE6.”

By the same token, you will work less in the long run, if you always make sure you know what you’re doing before you do it.

How To Plan

Be Productive Away from a Computer

This is a big one for me; I don’t spend a lot of time in one place, since I go to university full-time and work between classes. So, I make sure to always carry around a Moleskine notebook and a Bullet Space Pen, both of which are extremely worthwhile investments. That link is the best deal on Amazon for it, by the way; I checked.

When I’m waiting for a class to start, or for a bus, or anywhere else where it’s inconvenient to pull out my laptop (yes, that includes the can), I can spend a few moments scribbling pseudocode or sketching out database arrangements or page designs or notes for blog posts or whatever.

Define a Process

To define a process means to step back and look at how you usually do what you do. If you’re looking to design a process for complete web project, you should look at the steps you take. Meeting a client? Set the initial meeting location, which contract or forms to bring and have signed (you have a contract, right?), etc. Standardize your server setup process. Figure out what part you want to do first. Photoshop mockups?

Decide on the order and manner of going about things in a very specific way, and your time expenditure will drop dramatically. I just hope you’re charging by the project.

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.

With Apologies to Mark Twain

Mark Twain is one of my favorite authors, and my favorite work of his is an essay entitled “Fenimore Cooper’s Literary Offenses,” (which you should read) wherein he details many linguistic and logical violations commited by the aforementioned in his Deerslayer works.

In it he details 18 rules of writing which, while also damn funny, are quite applicable to anyone writing anything, including code with some coaxing. Thus, I give you:

Mark Twain’s 18 Rules for Writing Code

These 18 rules require:

1. That the program should accomplish something and arrive somewhere.

2. That each function in a program shall be a necessary part of it, and shall help to develop it.

3. They require that the functions in the program shall be functional, except in the case of abstract ones, and that the reader should always be able to tell the abstract ones from the others

4. They require that functions in the program, abstract or not, shall exhibit sufficient cause for being there.

5. They require that when the comments are left, the talk shall sound like human talk, and be talk such as human beings would be likely to talk in the given circumstances, and have a discoverable meaning, also a discoverable purpose, and a show of relevancy, and remain in the neighborhood of the subject at hand, and be interesting to the reader, and help out the program, and stop when the people cannot think of anything more to say.

6. They require that when the author describes the character of a function in the program, the behavior and output of that function shall justify said description.

7. They require that when a function reads like the work of an illustrated, gilt-edged, tree-calf, hand-tooled, seven- dollar Friendship’s Offering in the beginning of a class, it shall not read like that of a mechanical turk in the end of it.

8. They require that crass stupidities shall not be played upon the reader as “optimization.”

9. They require that the functions of a program shall confine themselves to possibilities and let miracles alone; or, if they venture a miracle, the author must so plausibly set it forth as to make it possible and reasonable.

10. They require that the author shall make the reader feel a deep understanding of the functions in his program and of their purpose.

11. They require that the functions in a program shall be so clearly defined that the reader can tell beforehand what each will do in a given emergency.

In addition, the author shall:

12. Do what he is proposing to do, not merely come near it.

13. Use the right method, not its second cousin

14. Eschew Surplusage

15. Not omit necessary details.

16. Avoid slovenliness of form.

17. Use good, and consistent, syntax.

18. Employ a simple and straightforward style.

To Sloan, Manufacturer of Automatic Bathroom Fixtures, Regarding an Overzealous Toilet

Dear Sirs,
I am writing to make public my dissatisfaction with the automatic flushing system present on the toilet in the handicap stall, in the third floor men’s washroom in the McPherson Library at the University of Victoria.

It is clear to me that the designer and/or installer of this particular system is a “stander,” by which I refer to his stance as he proceeds to employ the toilet paper. While I respect and tolerate this practice, I must cry foul at his design’s apparent disregard for the substantial “sitter” population present in the public at large.

The expected behavior of a toilet is to flush when the user has completed his task and is on his way to exit the stall. Additionaly, if such timing can not be obtained, the toilet must at least refrain from flushing while occupied. However, this rogue toilet flaunts both rules, for it is misconfigured in such a way as to trigger the flushing sequence upon the occupant leaning forward, a motion necessary to a sitter such as myself, as well as any person wishing to rest his elbows on his knees. This occurred at least 5 times during my last visit.

This is simply uncalled for. The fact that this toilet is designed for individuals whose movement is impaired, and consequently who may not be so agile as I, only makes the situation direr.

While I understand the impulse to err on the side of flushing, certainly a company with such a reputation for water-saving devices can see the benefit in a “lazy,” rather than “greedy,” flushing system. A toilet that only flushes once after a period of conclusive non-occupancy lasting at least 10 seconds would, in my opinion as a consumer, be a more reasonable choice. For situations in which the toilet has not flushed, it is a small thing for a human operator to push the button signifying a manual flush.

Additionally, in a final insult, the automatic sinks in said washroom steadfastly refuse to activate without a substantial debounce, and activate for a duration insufficient for proper washing.

I hope this letter will prompt you to revise your design.

Sincerely,
Adam Bard

P.S. Sloan the band is all right by me.

It’s not learning your first language. It’s not learning your second and third languages either. It’s not learning Lisp, Scheme, Ruby, Python, Erlang, Haskell, Perl. It’s not knowing C back-to-front, upside down. It has nothing to do with Java, script or regular, nor is it anything to do with Objective C, C++, C#, or D. It’s not even assembly language.

It’s not grokking recursion. It’s not using functional languages. It’s not understanding things like function currying, and other fancy tricks.

It’s not knowing the hardware down to the bits. It’s not programming for embedded systems, or for giant mainframe clouds. It’s not getting a Computer Science degree. It’s not working for Google, or Microsoft, or Sun, or IBM, or anyone. It’s not working for yourself, either. It’s not managing your time, nor is it managing others’ time. It’s neither agile nor extreme.

The hardest thing in programming is that no matter who you are, and what you’re doing, most of the time someone else has done it, done it better, and then released it for the world to see and use. Instead of re-inventing the wheel, your best course is to close emacs, and spend some of that time you were going to spend creating the world’s seven millionth web framework scheme reading documentation, and learn to live with it.

Although I never really got the hang of that currying business.

I’ve just been up most of the night developing my latest idea into a demonstration. The idea is a centrally-hosted Content Management System which can be dropped in to any existing web page (whose server supports php or python scripts.) I’m calling it “breeze.” Here’s the scheme, currently:

Users can sign up for an account. After this, they can define sites, then content areas, and then content. Each content area has a unique id and supplies to the user a small piece of php code to drop into the site:

$breeze->showContent(2);

Users include a script file provided and initialize the $breeze object with a secret key in the header of the page. Then, they can create as many variable content areas as they like. Content is served to these content areas from the central server.

No knowledge of PHP is necessary, save knowing whether your web server supports it.

Web designers will be able to provide clients with a login to let them edit content areas on their site, without having to design for a template as would be necessary for other CMS systems, such as Wordpress, Joomla, Drupal et. al. In effect, the CMS gets customized for the design, rather than vice-versa.

How It Works

The trick to this is a php socket connection to the Breeze server. In this Test Page, the gibberish on the page actually comes from a socket connection between adambard.com, located on a server somewhere in Texas, and my laptop in Victoria via dyndns. This service is superior to existing javascript-based options of a similar nature, due to the fact that it still allows content to be indexed and searched. (Edit: Proof)

In the future, I might provide an open-source admin interface that could be deployed on any given server, allowing anyone to serve—no, not serve… breeze*. Users will be able to breeze content to their clients, or even their own pages.

I think this could be a valuable service to any web designer or developer. What do you people who occasionally stumble across my blog searching for god-knows-what think?

*Everyone knows the secret to internet success it to turn your company name into a verb.