Rule #1: Use a Mailing List

How many times have you gotten an email with dozens (or hundreds) of names in the "To:" field? This is fairly common, but there are a number of downsides:

• You're forced to maintain a list of recipients in some other place -- like a Word or Excel document, then copy and paste them into the email.
• Everyone's address is visible to each and every recipient. This isn't very respectful to your audience, as some of them might not want their address shared in this way.
• You've taken the control out of the hands of your audience. They don't have a clean and easy way to unsubscribe (except, by mailing you and making you change the info in whatever file you're using to store stuff). And, it can cause your little email operation to venture dangerously close to spam (as in, unrequested email) territory.

One common way to handle the "visibility" issue is simply to enter every address in the "BCC:" field of your mail program. This nicely hides everyone's name and email. But, it doesn't ease your management burden or give your audience any additional control.

The solution is to use mailing list software. (Some old timers might call mailing lists "listservs", after a well-known example of the software.) A mailing list neatly solves all three of our problems:

• You can store and manage recipient names and emails.


• Emails sent to the list are delivered to each recipient individually, and the entire list's addresses are hidden from users.


• Your users can easily remove themselves from the list, if needed. And, as an added bonus, it is quite easy to set up a way for them to easily subscribe to your list, if that makes sense for your organization. Most mailing list software packages make it fairly easy to incorporate web subscribe/unsubscribe forms into your website.

If you have a website, chances are your website host offers mailing list software. The host I'm using for this very site (Dreamhost) offers users access to Mailman. Mailman isn't the easiest thing in the world to use, but it'll get the job done. And, if it is included with your website hosting package, it could save you some hassle and money.

Both Google and Yahoo have mailing list services, but those are really more geared towards discussion, not distribution of newsletters and the like.

There are also a plethora of for-fee services out there. I haven't used any of those, nor have I researched them, so I'm not going to recommend a particular one. A web search will likely turn up hundreds of options.

Rule #2: Time for maximum impact

Think in terms of "windows of opportunity" -- your goal is have your message arrive at a time when the user is most likely to read it and act on it. For a business audience, avoid the weekends (no one is working), and Mondays (catching up) and Fridays (on the way out the door). So, send messages on Tuesdays, Wednesdays, and Thursday. Shoot for mid-day. The morning rush is over, and folks are likely around mid-day (say, 10am to 2 or 3pm). If you're aiming for a non-business audience, maybe time your emails to land in the evening. Still, it is best to avoid the weekends.

Oh, and remember that not everyone checks their email obsessively, so if you want to make sure your message makes it, figure that it'll take some people a few days to actually open and read your message. Time your sending accordingly.

Note that some mailing list packages will let you "time" your message, so you don't have to actively send the message. Just queue it up and tell the software when you want it to be sent, and it'll handle the rest.

Rule #3: Keep it short

As with pretty much any form of communications, keep it short. Tell 'em what you need to tell 'em, then get out. 'Nuff said.

Rule #4: Go easy on the graphics

I get lots of fancy HTML-formatted emails these days. These are fine, but keep this in mind:

• Your message is more important than the design. If you don't have the time and the resources (read: talent) to make a fancy newsletter, don't.


• Many email clients (including mine) don't show images by default. So, your fancy design could end up looking far worse than a plain text message.


• Email clients are all over the map in terms of what they support and don't support, and how they display stuff. What looks good on your screen might look terrible on someone else's. It is worse than the old wild west days of web browsers. Check out Campaign Monitor's info on email design for more.

Okay, now that I got the "old crusty internet guy" rant out of the way, I will say that we do use HTML-formatted emails at work. But, the template is pretty conservative, and not at all image heavy. Keep it simple, or, better yet, keep it just text.

Rule #5: Don't bombard 'em

You'll need to figure out, depending on why you're communicating, the best timing for sending messages. It could be monthly, or weekly, or somewhere in-between. Send too often, and people start ignoring your messages. I get frequent messages from a few large internet retailers, and I tend to not even bother reading them at this point. So, respect your recipients, and don't load up their in-box!

That's it for now. If you have good tips to share, send 'em my way.

While I'm running the risk of being one of those smug techies who prattles on about the need for backups, I do fell compelled to say back your stuff up!.

The key to backups is that anything that requires either thought or action is doomed to fail. It needs to be automatic and foolproof.

You have two main options: local or off-site. At the simplest level, a local backup could mean just buying an extra (usually external) hard drive and using some simple software to back up your data. But, this doesn't meet the "automatic" test. And, if you're extra paranoid, you'll note that your data isn't safe in case of a fire, theft, or natural disaster. So, while this is the cheapest option, it isn't the best.

Another local option is Apple's Time Machine and Time Capsule. These are basically automatic, set-it-and-forget-it solutions (albeit, just for those with a Mac).

The other way to go with an off-site, internet based backup system. These programs back your data up to file servers in the "cloud." You don't need to buy an extra hard drive, or worry about the physical security of your backup disk. But, you will pay for it in either monthly or yearly fees. The programs run in the background, and (depending on settings) constantly upload your data to the service in question. The big downside (outside of the monthly costs) is a long initial backup run, as all of your data gets transfered up (subsequent backups will cover just the stuff that changed). But, there are two types of users who won't have a good experience: anyone still on dial up (yes, I know some), and anyone collecting a ton of data (think: professional photographer or videographer). For everyone else, this seems to be the way to go.

I'm currently using Jungle Disk -- a backup program that uses Amazon's S3 for storage. You pay only based on what you transfer and store, so if you don't have a ton of data, it might be a pretty good deal. (I'm getting to the point where I'm wondering if I'd get a better deal elsewhere.) I've also set people up with Mozy, a nice little service that charges $5 a month for unlimited space.

Of course, if you really want to make sure your data is safe, try a combination of local and off-site. I bet Time Machine + Mozy would put you in a pretty good spot.

Oh, and check out a recent post from Dan Benjamin on the topic. His take is a bit more technical than mine, but driven by the same desire to keep the baby photos safe!

I tried to keep this as bare-bones as possible. It is a ruby script, and it should work just fine on any shared host.

The script:

#!/usr/bin/env ruby

# Created by Karl Nelson, 1/16/2008

# This cgi script reads a YAML file (events.yml) and produces an iCalendar-formatted file

# that can be read by calendaring programs (iCal, Google Calendar, etc).

# The purpose is to display events that repeat annually, like birthdays, anniversaries, and such.

# I'm using this to track the important dates in my family.


require 'yaml'

$LOAD_PATH << './icalendar-1.0.2/lib'

require 'icalendar'

require 'date'

require 'cgi'

# Load data and various "constants"

cgi = CGI.new

events = YAML::load( File.open( 'events.yml'))

if cgi.include?('families')

  families = cgi['families'].split(',')

else

  families = ['smith']

end

years = [Date.today.year - 1, Date.today.year, Date.today.year + 1]

cal = Icalendar::Calendar.new

# Loop through the data, producing the events

years.each do | year |

  families.each do | family |

    events[family].each do | event |

      actual_date = Date.parse(event['date'])

      date = Date.new(year,actual_date.month,actual_date.mday)

      if actual_date < date

        ical_event = Icalendar::Event.new

        ical_event.dtstart date, {"VALUE" => ["DATE"]}

        ical_event.summary = event['event']

        ical_event.description = "#{actual_date.strftime('%m/%d/%Y')}, #{(date.year - actual_date.year)} years ago"

        cal.add_event(ical_event)

      end

    end

  end

end

# Send the data out...

cgi.out("text/plain") { cal.to_ical }

Because I have more than one "family" I'd like to track, and I'd like to let my relatives use this for their purposes, I've built in a way to specify (via a query string variable) which family it displays. Then, in the YAML file, just list the events like this:

smith:
    -
        event: "Uncle Earl's birthday"
        date: 1/10/1950
    -
        event: "Aunt Bessie's birthday"
        date: 1/11/1950

Feel free to use it any way you want...

• All (almost) Seattle Conference on Scalability videos now online


• Scalability slideshows on Slideshare.net (via Tim Bray)


• Sam Ruby's list o' links

(And don't forget Building Scalable Web Sites [Amazon]...probably the best place to start.)

I find the scalability stuff to be quite interesting. I file it under "a nice problem to have."

Late in his book, The Myths of Innovation, Scott Berkun quotes the inventor of the laser, who quipped that the laser was "a solution in search of a problem" (p. 144). I had the same thought as I read Berkun's interesting and engaging book. Berkun does a great job giving the reader an insight into the (somewhat squishy) concept of "innovation," and he skewers many of the myths that many of us hold on the subject. Yet, I kept wondering who this book was for and how the audience should react to the book.

I think some of the ambiguity I felt points back to the ambiguity around this word "innovation." Like the proverbial blind-men-touching-an-elephant story, "innovation" is a word that can mean different things to different people. Certainly, the image that first comes to mind is the scientist in a white coat, slaving away in the lab looking for the next big breakthrough in medicine, chemistry, or robotics. But that is a more limited view than what I think Berkun would say (although he is never very explicit on the subject). I think you'd be well advised to, for the purposes of this book, consider "innovation" to be synonymous with "change." I know I don't necessarily think of myself as an "innovator," but I do think a big part of my professional life is wrapped around getting people to change how they do their work (for the better, of course). Applying this definition makes this book seem broadly applicable. For, if your work life is at all interesting, you're likely engaged in producing new products or services, turning around a floundering organization, or pushing the boundaries of your field. (If you're keen on maintaining the status quo, this probably isn't the book for you.)

Berkun identifies ten "myths" to debunk. Heaven help the person who believes all ten of these myths, yet most of us will have bought into at least a couple of these at one time or another. The myths don't hold up well to scrutiny, as Berkun skewers them one-by-one (as outlined in the table of contents):

• The myth of epiphany
• We understand the history innovation
• There is a method for innovation
• People love new ideas
• The lone inventor
• Good ideas are hard to find
• Your boos knows more about innovation than you
• The best ideas win
• Problems and solutions
• Innovation is always good

In terms of content, there really isn't much to argue about here. I found myself nodding in agreement with pretty much everything he said. Stylistically, I'm a fan as well. Berkun is, as with most good communicators, a storyteller. The stories are one of the book's strong points, as Berkun is able to really drive home the point of each chapter with compelling examples. It also allows the reader to dive at random and not lose too much in the process. The stories also make the slim 150 page book a quick read.

I really enjoyed reading the book, but, as you've probably gathered, I finished it with a sense of unease. The book will likely be shelved in the "Business" section of your local bookstore or library, but it really doesn't fit there. One reads a business book (and I've read a fair number of them) looking for some take-away. Maybe the author is letting you in on the secret sauce behind a successful company, or learning about a new aspect of management or marketing. But I'm not sure I ended up with many take-aways from this book. Maybe it would help to treat this like many of the other non-fiction books I read. I read those simply because I'm interested in the world. You'd do well to approach Berkun's book with this same attitude; read it because he does a great job explaining how change happens, not because he's going to give you a point-by-point checklist to coming up with the next great theory of everything.

Regular readers will recall that I've written a decent amount about web analysis software. On a regular basis, I use ClickTracks, Mint, and MeasureMap (all for different sites, in different contexts). None are exactly ideal for what I wanted here, but each is a decent option.

Unlike at work, I think I'm comfortable with a hosted solution in this situation. But, I wanted some sort of notification system built in. I love MeasureMap's daily RSS feed, but it doesn't seem like many products have that sort of thing built in. Anyway, I started to do a little analysis of each of the likely candidates in the free/cheap market space.

Then, today comes word that Google revised their Analytics product. And, even better, it was the team behind MeasureMap that did the work. Long story short, the revision looks great, and it made choosing to go with Google a no-brainer. This is really, really impressive work, from a UI perspective. For more details see: Google Blog, Jeff Veen, and Avinash Kaushik (the last one being a very in-depth look at the changes). Really, go check this out.

Okay, enough gushing. Here's where I do a bit of whining. You see, I'm already using the Google Apps for Business service to manage the email for this little side project (at my domain). So, logic would dictate that I could use that account to sign up for Analytics, right?? If you said "yes", you'd be wrong. I'm unable to create an Analytics account with the the Apps account. So, I'm forced to create a *new* Google account for the Analytics. Meaning that I have now have two Google accounts. One wonders if Google has all of this infrastructure stuff figured out yet... (Of course, maybe I'm missing something obvious...let me know if I am!!)

#1: "That's a laptop??" -- the box was huge, and I think we all assumed it was a desktop tower with a big external monitor. Nope. In fairness, it did come with a docking station, stand, and bag. But there was still a *lot* of cardboard.

#2: "What? You don't read barcode?" says one of my co-workers as I tried to figure out what was what inside each of the boxes in the big box.

This might seem trite, but the initial user experience one gets with an Apple product is worlds away from what you see at Dell. Maybe the article above points to an initial attempt to improve this.

A couple of interesting things here:
* It is open source -- a very nice feature considering that many commercial products can be fairly pricey.
* The authors seem to emphasize ease-of-use with their "Two clicks - one click to find, one click to get" mantra. The commerical products I've seen tend to be *way* too complicated for most end users. That's a big reason why we rolled our own solution...

It is a curious ritual. In today's instant access, stat-happy world, this seems awfully quaint. I mean, a paper log! C'mon! And, in the age of DVRs (aka TiVo), the notion that I start and/or stop at show at 15 minute intervals is just silly. Still, I'm happy to do it, if only to show some love to a few of my favorite shows (granted, the Super Bowl eliminated a shows from the weekly watch list).

One other fun thing I noticed: the act of tracking my viewing changed what I watched. It became easier to turn off the TV rather than record that I watched some lame re-run. I wanted to make sure that I was watching the good stuff!

I guess this is why I'm such a big fan of unobtrusive data collection, like most web analytics. Surveys and focus groups are fine, but people will often tell you what they think you want to hear, rather than the truth. It is much better to observe actual behavior, especially if the observation can go mostly unnoticed.

Because this isn't a tech site I think we can assume that the population visiting is going to be more representative of the population at large than, oh, say, sites like this here blog. This is reinforced in my mind because two-thirds of visitors to this site come via search. Oh, that's the first interesting stat. In fact, it looks like only about a quarter of visitors type the URL in directly. (The remainder follow links from other pages.) I think this speaks to the power of search in today's internet.

Next, looking at the browsers in use, we have IE with 63%, Firefox with 26%, and Safari with 9%. I'm very surprised that Firefox and Safari are as high as they are. So, chalk this one up as a win for non-IE browsers. But, let's stay on the topic of IE for a moment. I'd assume that there would be a decent spread of users from older versions, like 5.x. But, I saw only a handful of users with 5.x. Nearly fifty percent of total visitors are using IE6, and a surprising 14% had IE7.

Fourteen percent of visitors were on a Mac, a number higher than I would have guessed. And, as a victory for designers who want more space, only 7% of users were running their monitors at 800x600.

Now, given that Mint uses javascript code to track stats, it is possible that older machines and older browsers aren't counted here. But, I was still surprised at how many folks are running very modern equipment out there.

I'm a big fan of the concept of backing up data to an internet-based server. You have the joy of letting someone else deal with the hardware coupled with the safety of off-site backups. As an added bonus, often the data is available over the web, making files handy to access at work, for example.

So, I've been on the hunt for the perfect solution to back my data up to the cloud. At first, I used Xdrive, back in the days when I was backing up a windows box. At the time, I actually had trouble with the service crashing my machine. I'm not sure if was the service or my box, so your milage may very on this one.

Next, I moved to Joyent's Strongspace, using rsync for the backup. I actually had this working really well on my windows box. But, I only had four or five gigs of space available, so I wasn't backing up any of our audio files, so that wasn't ideal. (More capacity was, of course, available, but it got fairly pricey.) On the plus side, they have a great web-based file browser. Then, I moved back to the Mac, and I wasn't able to get the system to work quite right. Something about the SSH/rsync/cron combo just wasn't working right, and I never managed to get the system working automatically. Then, Joyent changed their pricing, and the whole thing started to look much less appealing.

Thus, back to the topic of S3. After reading a bunch of info on the web, I tried out JungleDisk. This handy little app basically lets you access your S3 account in the same way you would access any local network disk. I've been using IMSafe to do the automatic backups. IMSafe seems pretty easy to use, if lacking somewhat in flexibility (ie, there doesn't seem to be a way to exclude directories from a backup). And, I'm not 100% sure I have everything working automatically yet. But, it looks like I'm able to do backups. And, so far, backing up to S3 seems to be much, much cheaper than the other options I've seen.

I just noticed that JungleDisk has added automatic backups to the list of features, so I'll be checking that out, too.

Update: Oh, yeah, I forgot to tell you the big problem with net-based backups. Doing incremental backups is fine and dandy, but doing the initial full backup takes forever!

Item 1: Christina Wodtke's Three-Pronged Fork in the Road, where she explains the three career options facing us (or, in this case, those who work on the web with an IA slant) as becoming a manager, becoming an expert, or becoming "you 2.0". I've taken the first fork, but occasionally feel angst about not taking the second fork, and wonder if I'm not actually closer to the third fork than I think.

Item 2: Ben Casnocha on cross-training your brain. Ben points to an interesting article on the topic in Fortune. From the article:

"It may well be a mistake to do just one thing," says Alvaro Pascual-Leone, a professor of neurology at Harvard Medical School. "If you practice multiple things you actually get better at any one of those things." In other words the benefits of practicing one skill are not limited to that skill alone; they can be transferred.

This, I love, if only because it quells some of the angst I occasionally feel about not being super deep in one given topic. Actually, let's not oversell this angst idea. I've always enjoyed being, in Ben's words, "a mile wide" (literally, not figuratively). Knowing a lot about a lot is generally a good strategy (unless one is looking for a job). And, I've purposefully taken up pursuits unrelated to my job and/or training (e.g. learning the violin as an adult) in order to stretch myself.

Item 3: Michael Ruhlman is fast becoming one of my favorite authors. Ruhlman writes about work and workmanship. It seems as if every book of his I've read so far (Wooden Boats, House, Charcuterie) has a strong theme of work running under the surface, occasionally becoming explicit. I imagine that his other books (a number on chefs and one about a hospital) keep the theme up.

My favorite of the three I've read was Wooden Boats, essentially an homage to the craftsman building an object (I almost called it a product) that Ruhlman juxtaposes against modern "plastic" boats--the epitome of our throw-away culture. I really should give it a more in-depth review...I'll put it on my to-do list.