Fast forward to 2009… who has even closed enough windows to see the icons on your desktop this year? Having a favicon has diminished in importance considerably. Do you even take note if websites you browse to have one or not?  Seriously?

But there is one thing that matters in 2009, as much as the favicon did in the late 90′s.  That is: the text & image which appear in Facebook when someone tries to link to you.

Helping people who want to help you? no brainer.  Make it a high priority, even if you do little else to promote yourself.  Make this experience pleasant; support the fans who are trying to promote you.  Neglecting them will hurt your reputation and your SEO pagerank (yes, that’s right, your buzzwords will suffer! .

Most websites fail this miserably.

Show some fan love? make the Facebook link to thing flow.

Who’s the boss?

Being that the client is the one who pays the bills, it is the developer’s job to please the client.  The developer doesn’t work for the client’s customers; the developer works for the client.  This is an important distinction in a “work for hire.”  If you agree to be compensated for your time, you give up ultimate authority over the product.

Yes, more compromise.  It isn’t easy for an artist to compromise his art, or for a developer to design & build solutions which he knows are sub-optimal.  Does the client even understand this stress, because the developer is an artist inside?  Some may, but most don’t care.  Business is business.

In a perfect world, leaders would trust the professionals they hire to have superior judgment in the field they’re professional in.  But the world isn’t perfect.

The man who pays is the boss.  And bosses have a right to make judgments and own them.  That’s how it goes.  If the boss isn’t willing to pay the price of shifting the simplicity to his customer, he’s the boss!  The artist inside may experience stress about this compromise, but the businessman says “ok” and moves on.

Do some clients make such bad decisions that the work will reflect negatively on the developer’s reputation?  Of course, and when that occurs, it is the developer’s responsibility to fire the client.

The advantage of growing and adapting your one software solution to many needs is a unified backend – but your offering becomes a “jack of all trades, master of none” solution.  With this approach, you’ll capture the low-hanging fruit–but leave 80% of the goodness unpicked and leave the solution unfitted to many situations.

The alternative is to introduce other tools into your toolbox. The problem with bringing more tools in is losing a unified data model on your backend.  Some would say (and they’re correct) that this makes your data more difficult to administrate.  When you put your customers first and resolve to deal yourself with the roughness, the simplicity shifts from you to them.  The front will be themed consistently so that users feel comfortable they’re in your brand, and your users obtain much more power and inherit less headaches–because you’re using a tool more closely suited to the need.

Even the mighty Facebook (with audacity to become the software that unites every user on the world wide web) goes with software diversity. Don’t believe me? see their developers wiki, which uses the software developed for #1 Wikipedia.org. Using the right tool for the task shifts the power and ease of use to the client.  In order to be the one solution that unites everyone, Facebook’s main software tries to be as minimal as possible, delegating as much functionality as possible to plug-ins & add-ons.  But when it comes to developers, they don’t even use their own versatile software at all; they punt and use MediaWiki.

Resources are scarce, and compromise is necessary.  I believe that the simplicity, beauty and power should be the inheritance of our customers, and the cost of complexity is the (unseen, under appreciated, misunderstood) problem of administrators.

This spring, I stumbled across Yahoo’s doctrine of the Standard Module Format while watching talks by @NateKoechley and Nicole Sullivan @stubbornella. Observing that the SMF structure was sufficiently versatile to represent all web modules I had styled for a year, I decided to adopt it as my own and try it out. Five websites later, I can testify that the convention

1. accelerated my rate of development,
2. made my code more accessible to others (through the use of standard terminology), and
3. facilitated software reuse (of CSS rounded corner drop shadows)

As I develop pages with more dynamic behaviors, I’m sure that Standard Module Format will continue to yield benefits.  I’d like to see a module naming convention like Yahoo’s become standard across all JavaScript libraries. Odd as it may seem, the idea of a standard module format is new.  Hopefully competing CSS frameworks and JS library developers will begin communicating as their ideas take form and compete for mindshare this year.