robert hoekman, jr. / blog
Note: This is the old blog for rhjr.net. The new one is here.
// rhjr.net / blog (formerly known as WidgetMaker)
Christian Cantrell reports that my blog, formerly located at WidgetMaker.net, in its new home at rhjr.net, is now being aggregated at MXNA. Thanks for setting that up, Christian.
// rhjr.net
Well, I've officially moved into my new home at // rhjr.net and replaced the homepages of my old sites with redirect messages to inform visitors of the move. Keep your eyes open for a section on XD, coming soon.
Up, down, repeat.
Someone once drew this image on a whiteboard in my office. Kinda says it all, huh?
rhjr.net: Worth the pain
All right, all right, all right. I give up. I started in the world of Flash geekdom with the loveAndRage.net domain, which I intended to use as a playground site, but ended up being used for my resume, client list, etc. I didn't really like using it for business purposes, but the domain had been mentioned quite a few times in print (well, online print) and I felt sorta stuck with it.
Then along came WidgetMaker. This site was meant to be a hobbyist site all about Flash extensions - tips on how to build them, free widgets, free source code - but no one who said they were interested in doing this with me ever posted anything. So I ended up using it as a blog about experience design and Flash. And now, WidgetMaker isn't really about widgets at all. And that makes it a pointless domain name (albeit, a pretty cool one).
To remedy the situation, I wanted to move the blog to a third domain, XDCafe, where I could focus entirely on experience design (XD). But when it comes down to it, I don't really want to do that. It's too limited. My blog is often about XD, but often about other things.
So, I began to search for domain names that were tied only to my name, and not to any specific topic. This way, I could bend the site's focus to my interests. It could change as I change. It could serve as an umbrella for multiple topics.
I must have checked 300 domain names before finally finding my soon-to-be-permanent-home. It drove me quite nuts for several weeks. Some domains were taken, some were too convoluted, and others just plain sucked. So I kept thinking about the one I started with: rhjr.net.
"Hmm. It's four letters long," I thought over and over again. "Nice and simple. Clean. Straight to the point. These are all good things. It may be a bit harder to remember than it could be, but hey, it's easier to spell than my last name, and it meets all the requirements. And I like it. Oh, and it's available."
So, there you have it.
I've already begun working on the experience of the site, and have gotten as far as flowcharting the site's structure and even doing a mockup or two. Heck, I even have the legendary Chris Georgenes working on an illustration for me (my idea, his amazing artwork) to use as a header (and likely the source of a visual theme). Things are rolling right along. I expect it will be a while before I'm ready to go live, but in the meantime, I've changed my email address with everyone I know, set up auto-forwarding on all my existing email addresses so I don't miss anything, and formulated a plan to make the transition possible without losing visitors. The plan is that I will keep my other domains, which have been mentioned in books and articles (and are therefore inescapable), and simply stick redirects on the old sites, re-routing users to the new site once it's ready. It will probably be years before I can finally kill the old domains once and for all (when they get no traffic for more than a month, I'll let them go), but I think it's worth it.
I finally have a permanent home I can live with.
Then along came WidgetMaker. This site was meant to be a hobbyist site all about Flash extensions - tips on how to build them, free widgets, free source code - but no one who said they were interested in doing this with me ever posted anything. So I ended up using it as a blog about experience design and Flash. And now, WidgetMaker isn't really about widgets at all. And that makes it a pointless domain name (albeit, a pretty cool one).
To remedy the situation, I wanted to move the blog to a third domain, XDCafe, where I could focus entirely on experience design (XD). But when it comes down to it, I don't really want to do that. It's too limited. My blog is often about XD, but often about other things.
So, I began to search for domain names that were tied only to my name, and not to any specific topic. This way, I could bend the site's focus to my interests. It could change as I change. It could serve as an umbrella for multiple topics.
I must have checked 300 domain names before finally finding my soon-to-be-permanent-home. It drove me quite nuts for several weeks. Some domains were taken, some were too convoluted, and others just plain sucked. So I kept thinking about the one I started with: rhjr.net.
"Hmm. It's four letters long," I thought over and over again. "Nice and simple. Clean. Straight to the point. These are all good things. It may be a bit harder to remember than it could be, but hey, it's easier to spell than my last name, and it meets all the requirements. And I like it. Oh, and it's available."
So, there you have it.
I've already begun working on the experience of the site, and have gotten as far as flowcharting the site's structure and even doing a mockup or two. Heck, I even have the legendary Chris Georgenes working on an illustration for me (my idea, his amazing artwork) to use as a header (and likely the source of a visual theme). Things are rolling right along. I expect it will be a while before I'm ready to go live, but in the meantime, I've changed my email address with everyone I know, set up auto-forwarding on all my existing email addresses so I don't miss anything, and formulated a plan to make the transition possible without losing visitors. The plan is that I will keep my other domains, which have been mentioned in books and articles (and are therefore inescapable), and simply stick redirects on the old sites, re-routing users to the new site once it's ready. It will probably be years before I can finally kill the old domains once and for all (when they get no traffic for more than a month, I'll let them go), but I think it's worth it.
I finally have a permanent home I can live with.
Defensive Design for the Web
I just finished reading Defensive Design for the Web, the first book by renowned usability firm 37 Signals, and I thought I'd do a quick write-up so everyone else on the planet knows what I now know.
Overall, this book is something every developer should have on his/her desk, because it would serve as a constant reminder that we can do better. The book is filled with advice on how to get users back on track when things go wrong, and features examples of sites that handle contingency design in both positive and negative ways. And if you want to know how your site rates, there's a test in the back of the book to see how well you do against user mistakes, invalid URLs, and other common problems.
That said, there are a few small things about the book that bothered me. First, some of the information is redundant and/or contradictory. For example, one of the sites identified as a positive example told users, via a JavaScript alert, when they had chosen a model type from a dropdown menu that was incompatible with the chosen product type. But elsewhere in the book, there's an entire section titled "If customers can't choose it, don't show it", which explains that sites should only expose valid choices to users. In this, and a couple of other cases, 37 Signals inadvertantly tells readers to break the very rules they say elsewhere to follow.
Second, the book often suggests using verbose lists, instructions, or descriptions to get users back to the right place after an error occurs (say, a 404 error). This bothers me because I, and many other people, know that users don't read lists, instructions, or descriptions if they appear even the slightest bit unnecessary. Every web usability book and expert out there says as much, and usability tests prove it constantly. While I understand that 37 Signals is telling us to give the users everything they could possibly need to get back on track, the writers have forgotten about some of the core usability principles upon which their firm is built.
When you look closely, 37 Signals may not have been the best choice to author the book, but the book itself - its concept, purpose, and approach - is very necessary and very worthwhile. Despite its flaws, you should get yourself a copy and memorize it. Live it. Breathe it. Have it for breakfast.
Sidenote: When you visit the 37 Signals web site, you'll likely see an ad for Basecamp, their online project-management system. I tried out the free, single-project version of this, and I gotta say, I didn't like it. It wasn't nearly as intuitive as I would have liked, and its inability to be customized was a real turn-off. Ultimately, the tool ... well ... got in the way of its purpose. But hey, that's another post.
Overall, this book is something every developer should have on his/her desk, because it would serve as a constant reminder that we can do better. The book is filled with advice on how to get users back on track when things go wrong, and features examples of sites that handle contingency design in both positive and negative ways. And if you want to know how your site rates, there's a test in the back of the book to see how well you do against user mistakes, invalid URLs, and other common problems.
That said, there are a few small things about the book that bothered me. First, some of the information is redundant and/or contradictory. For example, one of the sites identified as a positive example told users, via a JavaScript alert, when they had chosen a model type from a dropdown menu that was incompatible with the chosen product type. But elsewhere in the book, there's an entire section titled "If customers can't choose it, don't show it", which explains that sites should only expose valid choices to users. In this, and a couple of other cases, 37 Signals inadvertantly tells readers to break the very rules they say elsewhere to follow.
Second, the book often suggests using verbose lists, instructions, or descriptions to get users back to the right place after an error occurs (say, a 404 error). This bothers me because I, and many other people, know that users don't read lists, instructions, or descriptions if they appear even the slightest bit unnecessary. Every web usability book and expert out there says as much, and usability tests prove it constantly. While I understand that 37 Signals is telling us to give the users everything they could possibly need to get back on track, the writers have forgotten about some of the core usability principles upon which their firm is built.
When you look closely, 37 Signals may not have been the best choice to author the book, but the book itself - its concept, purpose, and approach - is very necessary and very worthwhile. Despite its flaws, you should get yourself a copy and memorize it. Live it. Breathe it. Have it for breakfast.
Sidenote: When you visit the 37 Signals web site, you'll likely see an ad for Basecamp, their online project-management system. I tried out the free, single-project version of this, and I gotta say, I didn't like it. It wasn't nearly as intuitive as I would have liked, and its inability to be customized was a real turn-off. Ultimately, the tool ... well ... got in the way of its purpose. But hey, that's another post.
RSS feed