“It’s certainly different, but requires more know-how and the difference won’t be felt by 90%+ of those who would consider it.”

I don’t want to post a lengthy article, but I thought I would try to back my claim with a little bit of math.  Fair warning: this is common-sense math that might not hold water in real-life situations (somewhere between damned lies and statistics?) so you are forewarned.

Cloud hosting differs from “normal” hosting in that the host services are distributed across multiple servers. In theory, something as simple as running a web server alongside a separate database server could be considered a form of “cloud”.  However, the typical selling point of cloud hosting is extreme scalability–that you quickly expand your website to run on many servers at once, and later turn off or simply discard spare servers when they are not needed.

This is a very attractive option for large sites and web services, as traffic–and thusly bandwidth, CPU and other resource usage–varies widely by time of day, and by day of week. The traffic to any given website in a 24-hour period resembles something like this:

Consider a website that requires ten servers to operate at peak usage.  Cloud hosting seems like a very nice option:

During non-peak hours, the website can run on as few as two servers.  By not having to pay for the remaining servers when they are not needed, the website can save a significant amount of hosting costs.

However, these advantages of cloud hosting are not as great for smaller operations.  Consider a smaller website that only requires two servers to operate at peak usage:

For a smaller website like this, cloud hosting provides far less control and with far greater risk.  The operator of the website must make a choice: turn the second server on early and incur additional hosting costs, or delay turning on the second server as long as possible, and risk site performance issues.  And because the required “turn-on” point occurs when traffic is climbing at its fastest, the risk of performance issues is a very real thing.

Still, there will be a period of time at which the website simply will not need a second server.  The website operator must decide if that downtime will result in actual savings over a traditional virtual dedicated hosting plan.

To get a very rough idea, I have specced out comparable plans between a GoDaddy VPS and a “cloud” of two Amazon EC2 “small” servers:

I tried to give Amazon every possible advantage in this case–I’ve neglected to take GoDaddy’s 12-month discount into account, and I’ve specified an extremely low amount of data transfer for a website that would require such a meaty hosting plan.  Even still, the EC2 solution is only competitive in price if the second server sees 33% or less utilization. And were I to expect greater bandwidth requirements, Amazon’s cost quickly becomes much more expensive.

There are costs to cloud hosting well beyond dollar amounts, as well.  Upgrading to a “cloud” environment introduces many new layers of complexity–load balancing, instance management, network file handling, and much much more.  Amazon’s administrative console is extremely powerful and helpful, but even still, the learning curve can be incredibly steep.

I don’t mean to make a case against cloud hosting.  It really is an amazing tool for an organization that needs to scale, and scale big.  I would simply caution this:

Do not overestimate your need for cloud hosting.

If you are first and foremost a web designer, and you aren’t what you would consider a “server guy”, cloud hosting is probably beyond your needs and will definitely overwhelm you.  If you are more savvy, or are in a large enough organization to have one of the aforementioned “server guys”, block out a good amount of time for learning in-depth about cloud hosting and developing a plan for when and how to best implement it.

P.S. I also don’t mean to paint Amazon in such a poor light.  I use them as an example simply because they are the best cloud example.  For reasons greater than simple math concepts, I would still recommend an EC2 a million times over a GoDaddy VPS.  (I would simply not recommend a GoDaddy VPS, period.)

For anyone who cares, these are my personal recommendations for choosing virtual/cloud hosting.

• Avoid GoDaddy. The numbers are very competitive, but in my experience their servers are extremely inundated by “bloat”.  I suspect they also spread CPU resources very thin.
• Avoid the Amazon “Free Tier” EC2. This may seem like a great starter solution for web hosting, but there are often hidden costs related to disk usage. Consider this option only for testing the Amazon platform.
• For small servers, consider Linode. This is where I currently reside.  The numbers on its pricing plans seem less competitive than GoDaddy, but the quality of the hosting service and environment is top-notch. (Disclaimer: If you sign up via the link above, I will receive a referral in the form of a discount. This does not affect my opinion of Linode, but I can most certainly appreciate discounted hosting costs.)
• Watch the Amazon Large EC2. When you can afford it, or when your website starts to outgrow something like the Linode 1536, jump to Amazon and settle in on a Large EC2.  At this size, I feel Amazon becomes far more economical than any other option.  You still don’t need cloud computing yet, but when you do, you’ll be on a platform that’s more than capable for doing so.

Lately, I have been asked one question more than any other question–heck, more than all other questions combined: “What phone should I buy?”  Part of my day job is spent supporting computers, browsers, email, and network connections…  And yet no one asks me about those things in passing.  It’s always about phones.  Nearly a decade after we first chuckled over the weird guy obsessed with his oversized CrackBerry…  We’ve all caught the addiction.  This is the era of the smartphone.

So…  What should you buy?

Forget about BlackBerry and Palm.  They have missed the window of opportunity for attracting developers, and a smartphone without software…  just isn’t very smart. Microsoft has actually done some interesting things with the Windows Phone 7 user experience, but I would consider its new OS an “unknown” for the time being, as Microsoft has a tendency to produce neat gimmicks with very poor follow-through.

Really, then, this becomes a simple either/or scenario: “iPhone or Android?”

Of course, to many technology fanboys, that is no simple question, but rather, fuel added to the fire of their latest holy war.  Apple hipsters will tout the iPhone’s ease-of-use; Google advocates will mention the open platform.  iFans will brag that their demographic gets laid more, and Droid-heads will…  Mention some cryptic thing about how nice “user intents” are, whatever that means.

I guess my overlap of fandom–I love my MacBook Pro, but I eat and breath Google Apps–has left me in a position to offer a fairly objective opinion: It really comes down to what your needs are.  There are a few very important questions that should guide your decision, and otherwise it simply comes down to preference.  Those questions, in order of importance, are as follows:

1. Do you have a deep-seated hatred for AT&T? I couldn’t blame you…  Their logo, until recently, did bear an uncanny resemblance to the Death Star.  All signs point to Apple breaking free from its bonds with AT&T in the near future, but for now…  Go Android.
2. Is it important for you to have music, movies and photos with you on the go? Apple’s experience with iPods and iTunes give it a clear advantage, although Google is making plans to catch up in the next version of its OS.  Still: Go iPhone.
3. Do you rely on Google’s Gmail, Documents, Calendars, and other Google Apps? Fortunately, most of these apps perform equally well (or poorly) on both platforms.  However, Apple has been known to block some Google apps in the past, and there’s nothing stopping them from doing so again in the future.  And of course, nobody is going to know Google Apps–and Android–better than Google.  Go Android.
4. Is important for you to be able to customize and personalize your phone software and user experience? Apple likes to control the user experience, so they don’t allow apps to take over any of the default functionality of the phone.  Tired of the default iPhone SMS interface?  There’s an app for that–but good luck getting it to use your unlimited texting plan, or accessing it from your Address Book contacts.  Android, on the other hand, gives users the freedom of choice.  I run a custom home screen, lock screen, and SMS app.  I have multiple map apps, browsers, and camera apps installed, and could easily set one of them as the “default application” for those duties.  All of these apps, and the many UI elements provided by the Android OS, interact and play nice together.  This is my single favorite feature of Android, and I wish there were a desktop OS that handled these interactions so elegantly.  Granted, most people don’t require this level of customization.  But if you’re a tinkerer…  Go Android.
5. Is it important for your phone to be extremely simple to use? Android has gotten knocked for having a less-than-elegant UI, but as of “Froyo” (version 2.2) I believe it is nearly as clean and user-friendly as the iPhone’s.  I say “nearly”…  Apple is the king of polish, and there are certain specific actions (e.g. selecting text on a web page) that are still just a million times easier on iPhone.  These are features you won’t realize are missing on an Android phone until you need to use them–and many people never will.  But if you want a stupidly simple smartphone, and I mean that in a good way: Go iPhone.

There are many extenuating circumstances that can trump this list, of course: carriers, coverage, keyboards, form factors…  Android, being on multiple phones and carriers, is a bit more accommodating to these circumstances.  But really, if you didn’t answer “yes” to one of the questions above, it comes down to user preference.  If that’s the case, then congratulations are in order…  Hopefully, whatever choice you make, you can remain a somewhat neutral party, avoiding the fanboy wars that will continue for a few years to come.

Caveat emptor: Android mileage varies greatly by phone manufacturer and carrier.  Android phones from T-Mobile or from Motorola’s Droid series are generally safe, HTC-branded phones have some rather invasive UI customizations. The Samsung Galaxy line of phones have made waves as the “alternative to iPhone”, but in a cruel twist of fate, some stock Android features are just plain broken in the Samsung UI.  And some cheaper phones are simply underpowered.  In lieu of writing an article about “Which Android phone should I buy?”, I will happily do my best to field any questions left in the comments.

Last year, this blog felt very much like a placeholder.  It was a placeholder, actually…  My plan had been to run WordPress as a temporary solution, build my own website framework, and bulldoze this place when I was done.  My framework, Escher, is now built and in a pretty good spot–it’s really going to make website development a much easier task for me.  But I must be honest: it’s no WordPress.  WP does blogging very well, so why switch?

Having had that epiphany, I decided it was time to pretty the blog up.  This theme is a “blueprint” variant on the theme I’ll soon be using for my portfolio website.  Not quite as pretty, but still fun.

I’m going to tweak the focus of this blog, too.  While still about technology, design and the web, I’ll try to keep things a lot less technical.  Every now and then, someone will ask me a question at work and I’d love to write a blog entry to point them to…  That’s the type of content I will be working towards.

$(‘textarea’).textpandable();

…and voilà!  All of your textareas are expandable, like this:

Textpandable offers the following options:

• lineHeight: Specify the lineHeight of the textarea–as a Textpandable option or a CSS declaration.
• minRows and maxRows: Set limits to how small or big your textarea will expand to.
• padding: Set a number of extra rows to provide for “padding”.  1-2 rows is usually a good value.
• width: Number of characters to allow per line before adding an extra row.  If not set, Textpandable tries its best to determine safe values based on CSS declarations, col attributes, and/or pixel width.

Now, I’m calling this version 0.9 for a few reasons:  I haven’t tested this in IE yet, and I haven’t documented the code (although it’s really simple)…  but most of all, it’s not feature-complete: I want to get animations working.  Unfortunately, with animations turned on, any change in size causes the cursor position to skip to the end and/or lose focus.  I’m not experienced enough with the innards of jQuery to know why this would be happening.

It works just fine with the default speed setting of ’0′ (as I’ve short-circuited the animation script in this case).  Anyone who gets animation working will be my hero!

Download Textpandable v0.9 (Dual-Licensed MIT & GPL)

During this redesign, I realized two things: First, I take a different approach to CSS image rollovers than most people seem to.  Second, my unorthodox approach really came in handy this time.

Here’s a screenshot of what the new design looks like:

It’s a semi-fluid design that’ll stretch anywhere from 1000 to 1200 pixels and, beyond 1200 pixels, will remain centered in the window.  There are also a number of different background images stitched seamlessly together to provide both the full-width gradient and the starburst pattern behind the logo.  Here’s an outline of some of the major layout elements:

The outlines represent the dimensions and positioning of each element, and the shaded portions represent the background image position.  It looks relatively simple, but there were a lot of difficult issues involved–either the starburst pattern was getting cut off to the left, or the main content area was too skinny, or something. The CSS image rollover for the bucket logo was actually the least of my concerns–but only by happy accident.

The “holy grail”, and most common implementation of CSS rollovers is the single-image rollover, illustrated below:

Typically, the background image contains two “sprites”, and you manipulate the background position to display either the default or active sprite, one or the other.  This works just fine, and I think it taps into the visual metaphor of the “sliding door” that is so popular among CSS gurus.

However, I’ve always done my rollovers differently.  (When don’t I do things differently?  It must be because I’m self-taught.  “Never had one lesson,” as Ferris Bueller would say.)  Take a look:

Here we have two HTML elements: the #title link, which will be on the receiving end of our rollover; and its parent element, the #side_margin div.  I’ve always just made the background image of the parent element handle the default state of the rollover.  Meanwhile, the background-image of the #title element is positioned out in la-la land, in negative-pixel territory…  out of sight.  When the #title’s :hover state is fired, its background-image is repositioned into view.  Tada, rollover.

I call this the “quantum rollover” because, well, it really doesn’t exist until you observe it, right?  Geeky, I know.

Is this approach better or worse than the “traditional” CSS rollover?  I’m not sure.  I think it’s better in some cases, worse in others.  I do think my approach has an advantage if your parent container is already going to include a background image–as is the case with the starburst pattern in the SmartPopcorn design.  I also think that, because I’ve approached my rollovers this way, it’s helped me to keep my designs smoother, softer, and less claustrophobic or “boxy”.

What do you think?

What?  You think I want four hours of slow Web sites?  Of inaccessible Gmail?  Nosiree.  I hate the thought!  But here’s another thought:  Email goes down, doesn’t it?  Whether it’s Gmail, or POP, IMAP, or Exchange, sooner or later, we experience a little downtime.  It happens.  Of course, when you have to call someone and say, “Sorry, I didn’t get your email, my corporate Exchange server is on the fritz…”  That just sounds bad, doesn’t it?  Looks bad for your company, and for you.  Google?  Well, that’s another story.  Nobody could blame your company for going with Gmail, because it’s a great deal.  And when the shit hits the fan, nobody’s going to look down on you because somebody at Google screws up.  (Unless you work for Google.)  And as we can see this week, EVERYONE will know when Google screws up.  So, in a sense, Google gets to play the patsy and subsidize our would-be embarrassments.  No longer is it Joe in IT’s fault…  It was the GoogleFail, you know, the one all over the news.

Which, might I add, is silly.  This should hardly be newsworthy.  I’ve been on Gmail for more than four years, and in those four years I cannot recall more than eight hours in which Google has been less than 100% operational.  That’s about 99.978% availability, and I would consider that a conservative estimate, as many accounts were probably still freely available during those incidents.  (I have never personally felt the effects of ANY of Google’s outages.)  That’s at least as good as my web host, it’s at least as good as my email at work (probably significantly better if you’re counting slowdowns as downtime), and it’s probably about as good as the small server cluster my team runs at work, which has far more redundancy than it even has points of failure.  So Google (and by proxy, “the cloud”) is at least as reliable as non-cloud technology…  It provides everywhere access and features (such as collaboration and interoperability) that local technology typically can’t touch.  And as previously established, when it IS down, it’s not your fault.  How is that not a win-win situation for everyone?

So yes…  I say bring on the cloud: slowdowns, GoogleFails, and all.

The concept of a “CSS Reset” is embarrassingly new to me–I only read about them a month or two ago.  Of course, 90% of what a reset does, I have done manually for years, but I stupidly never thought of separating the styles out that way.  When I read about resets, I was initially turned off because many of them seem way too aggressive.  (Upon searching for validation, I indeed found that it I wasn’t the only to dismiss resets as a bad thing.)

I’m a stubborn person, but fortunately I seem to be capable of talking myself out of stubborn positions.  A week or two back, I decided to try out the use of a reset, to see (A) if I liked the setup, and (B) if it seriously borked any of my recent work.  Looking around, I didn’t find any that did exactly what I wanted a reset to do.  The closest was a reset unofficially credited to Shaun Inman, although it appears to be itself modification of the popular YUI reset.  It was as good a place as any to start, so I began to flesh out my own personal reset script.  Here’s what I came up with:


/* "Voodoo Child" CSS Reset by Thom Stricklin. Based on W3C defaults, YUI and work by Shaun Inman. */
body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,input,p,blockquote,table,th,td,embed,object {
padding: 0; margin: 0; outline: 0; }
table { border-collapse: collapse; border-spacing: 0; font-size: 1em; }
fieldset, img, abbr { border: 0; }
address, caption, cite, code, dfn, th, var { font-weight: normal; font-style: normal; }
caption, th { text-align: left; }
h1 { font-size: 2.0em; }
h2 { font-size: 1.50em; }
h3 { font-size: 1.17em; }
h4, h5, h6 { font-size: 1.0em; }
h1, h2, h3, h4, strong, b { font-weight: bolder; }
h5 { font-weight: bold; }
h6 { font-weight: normal; }
q:before, q:after { content: ''; }
a, ins { text-decoration: none; }
sub { vertical-align: bottom; font-size: 0.67em; }
sup { vertical-align: top; font-size: 0.67em; }

/* Slight Return. These settings are more likely to change from project-to-project. */
h1,p,blockquote { margin-top: 0em; margin-bottom: 0.5em; }
h2,h3,h4,h5,h6 { margin-top: 1em; margin-bottom: 0.5em; }
ul, ol, blockquote, dd { margin-left: 5ex; }
.block-list li { list-style: none; }
.inline-list li { list-style: none; display: inline; }

A few things my reset does differently:

• This is a reset…  and then some.  The new rules I set are too modest to consider a CSS framework by any means, but they do go beyond a standard reset.  For those who would prefer just the reset, just take out everything after the “Slight Return”. (Yes, I am a dork.)
• I do not set all headers to 1em.  Rather, I went with a mix of the W3C “default” values and a little common sense: It’s pointless for H5 and H6 to be smaller than 1em so, instead, I decrease their font-weights.
• I treat H1 differently than other headers.  The train of thought is that H1′s will most likely appear at the top of the page, and so will not require a top-margin value.  H2′s and beyond will appear in the middle of page content and will probably look better with some extra separation.
• I do not reset the default list styles.  Lists-as-layout are very popular now and rightfully so, but they’re still great for normal lists–like this one–too.  I do provide “block-list” and “inline-list” class declarations for quickly & easily achieving headless lists.  I’m not sure how useful they are, though…  I’ve already encountered a case of a list that will be displayed as block for screens, but inline for iPhone/mobile.
• I fiddle with the display of sup/sub tags.  This behavior is out there in other reset scripts, but unfortunately I did not save my source for this partiicular solution…  Sorry!

I hope this reset script might be of some use to others.  More importantly, I hope this might help to open some minds about reset scripts.  They really are just a set of tools we each can choose to use…  or not use.  But we can forge our own tools.  We can write our own resets to our liking, so why not?

I personally oppose making our browsing experience dependent upon “workspaces” or categories…  It would take too much work for everyday browsing, it’s presumptuous to expect it would actually match most people’s browsing patterns, and it’s only adding another layer of organization to the browser, as tabs (or whatever tabs become) are still in there somewhere.  Workspaces could be useful for advanced users, but let’s not build our browser around them.

I do, however, like the general trend towards moving things into the sidebar.  As I commented on Mozilla designer Aza Raskin’s blog, there are many reasons to consider this a good move.  In fact, I say let’s take things to the next step and move the entire browser UI into the sidebar.  I spent an evening in Fireworks layout out such a design, and here’s what I came up with:

I probably went just a bit too extreme on how compact I made the sidebar (which of course, ought to be resizable anyway) but I wanted to drive home the point: done right, this exodus to the sidebar can improve simplicity, usability, and aesthetics.  The sidebar is the new awesome bar.  I’ll break things down by component:

• Address Bar/Awesome Bar: Firefox (and Chrome, too) have gone a long way to making the address bar more useful, and ubiquity will take us even further down that road.  But there’s still one big problem: it’s a real-estate hog.  Most of the time, if I ever even type in an address these days (more likely I’m following a link or a book mark), I just type, press enter, and forget about it.  Why is it constantly hovering over my window?   When it doesn’t have focus, it should condense down and slide into the sidebar.  Give my web page the full height of the screen to work with.  When you click into the space–boom–it slides back out for you.  It might also be a good idea to provide a delete button on-hover (a la OS X/iPhone search fields).
• Back, Forward, Reload/Stop, and Home: The only four buttons we need.  Even in the current Firefox incarnation, these would easily fit into the sidebar, so why not?
• Apps: Not sure where this idea originated, but it was on Aza Raskin’s mock-up, and I think it’s a great idea.  I hope these are not just “supertabs” in that they stick to the top, but that they provide additional functionality: Available in all windows, always open in the background, personalize the name in sidebar, etc.  I think the option to “maintain a separate cookie/session” for an app would be a neat idea too, as we could then maintain a “Personal Gmail” app and a “Work Gmail” app running without interference, and without the need for an addon.  I also think that Mozilla, Google, and Apple should work together on some sort of web application notification system (some extension of the dom or the navigator object).  As we think of web sites more and more as applications, we need to have the level of interactivity that we’d have with desktop apps, and flashing a message in the title attribute just doesn’t cut it any more. We should have both numeric notifications (i.e. 9 new messages, as pictured above) and Growl-style textual notifications.
• Tabs: Not much to this, except I do think it’s important to give users a “show all tabs” button.  Let’s not be so concerned about doing things “the Firefox way” (differently) that we fail to acknowledge a good user interface element when it comes around.
• Bookmarks, Feeds (Not Pictured), History, Addons: What’s great about this sidebar approach is that it really unifies the interface.  All of these components can look the same and function in the same or similar manner.  It also leaves it so that browser components are competing with each other for real-estate, not with the page content.  I envision most of these components (except bookmarks) being collapsed by default, and expanding on-click accordion-style.  They can either take up as much space as they need, or take over the whole sidebar, collapsing the other components.  But once you click away from the sidebar, they collapse again.
• Themes/Styles: I know absolutely nothing about the current means of theming Firefox, but make this sidebar CSS-driven and I could create an entirely new theme from scratch in about five minutes.  In fact, we could build customization into the browser (think similarly to Twitter’s interface) and let users set their own colors, backgrounds, etc.

A word of caution: let’s not throw out the baby in favor of trendy new bathwater.  In my experience, most Firefox users do not use 20 tabs at once.  They do not keep certain pages open, app-style, at all times.  They’re perfectly happy with the current user interface, and if we completely abandon it, they will balk and move to Safari or Chrome or even IE8 for a more familiar experience.  (See: Winamp.  How many of us switched to iTunes when the ridiculous Winamp 3 UI came out?)  So we need to think out a way to make this new UI work both ways, and probably give users the option when they upgrade: UI elements at top (Firefox 3) or on the side (Firefox 4).

That said, if the next version of Firefox resembles this in any way, I will be eagerly awaiting the 4.0 beta.

So, while @thomshouse has been around for a while, I’ve never had any desire to be an active user on Twitter.  Until now.  And it’s all Facebook’s fault.

Facebook is riding the fail whale today.

See…  I don’t want to walk down the street holding hands with Twitter, but I do want to maintain a presence.  Why?  I dunno.  I suppose I too like to hear myself speak.  Or perhaps I would like to have some content there, on the off chance that Twitter might become a major avenue of communication for me–say, because of a side project or freelance work.  I’m definitely a technophile, so that weird obsessive craving to tinker with everything is there, too.  But most of all I want to maintain a presence on Twitter because it should be effortless.  With social APIs left and right, I should be able to post my status on Facebook and see it updated on Twitter, FriendFeed, MySpace–everywhere.

And that’s what I’ve been doing.  I update my status in Facebook, and through a roundabout process provided by a Facebook app called “Twitter Updater”, I’ve been able to see my status updates in Twitter, usually with less than a minute’s delay.

Until today.  Today I updated my FB status on my iPod, jumped into Tweetie to make sure it took, and…  nothing.  Checked again a few minutes later, and still no update.  Numerous posts have since appeared from the people I follow, and meanwhile, crickets chirp over my lack of an update.  I grew suspicious.  Logged into FB to investigate, and sure enough, the powers that be disabled Twitter Updater’s ability to function.

A little background: Facebook doesn’t make it easy to share your status with other services.  As I understand it, Facebook’s APIs expose the ability to update your status, but not to read it.  It would seem that applications used to have this ability, but it has since been disabled.  Twitter Updater got around this “shortcoming” (or crippleware?) by having you add a bogus friend–in my case, a Mister “Twitter Updater II”–to your friends list.  The application couldn’t read your status, but your friend T.U. sure could, and voila!  Twitter updates via Facebook.  At least, that’s how it did work.  Now, Facebook has disabled the friend accounts, supposedly on the basis that they “do not represent real people”.  They have also completely obfuscated access to your private “mini-feed”, an RSS file that can provide another means of export.

I believe, however, that this–and all other means to cut off access to Facebook status updates–is a result of (Facebook founder) Mark Zuckerberg’s love/hate relationship with Twitter.  Those that follow tech news probably know that Zuck was infatuated with Twitter as of last fall, that Facebook attempted to acquire Twitter with a $500 million stock deal, and that Twitter turned it down.  And Facebook users are all-too-aware of the much-maligned changes made to the home page recently, changes that seem designed to suspiciously resemble a Twitter-like functionality.

It seems to me that this crackdown on API status access and on services like Twitter Updater are just another piece of the puzzle.  There is no justifiable reason for Facebook to lock down status access.  Applications can already be granted access to your name, friends list, birthday, and who knows what else from your profile.  And if there’s anything Facebook’s done spectacularly, it is the detail and granularity of privacy controls to block or allow applications access to this information.  So it can’t possibly be a privacy concern.  No, it’s got to be a business model.  Facebook is blocking access to the status to prevent an exodus, or perhaps just to spite the competing service.  Mark Zuckerberg is the jealous, possessive lover: if he can’t have Twitter, no one can have Twitter.

...or maybe Zuck is like Kathy Bates in Misery?

I would love to be proven wrong.

I would love for someone to answer these two questions:

• What legitimate reason is there to cut off access to status updates?

• Won’t this move actually hurt Facebook?

I like Facebook.  I’m a UI snob, and I prefer its aesthetic. I would much prefer to use Facebook and be able to ignore Twitter altogether.  Is it really better for Facebook that I am now forced to “reverse the flow”, to update Twitter and spend less time directly on Facebook?  Because that’s what I’m doing now.  I am updating from Twitter, and using Facebook less often than I used to.  Good business model, FB.

Anyone who feels my pain or likes this article can follow me @thomshouse.  I’ll be on there a lot now, it seems!

I’ve had my Twitter account since March of last year.  How many updates–or tweets, or whatever the hell they call it–have I posted?  Six.  Half of which are about “trying this Twitter thing again”.  Everybody seems crazy about it, but I just can’t get into it.

I can sort of understand the appeal.  The reason I gave up on the old version of my blog (which was personal, not tech/rant-related) was because it was too cumbersome…  I felt like I had to write a novel to justify posting anything.  So I looked at microblogs.  Tried Tumblr, and I liked the concept, although it was still enough like a blog that I rejected it for being a hosted solution.  (The original drive behind Escher was to develop an open-source microblog similar to Tumblr.)  I started using my long-dormant Facebook account and found a satisfying outlet via status updates.  Then Richie started talking up Twitter, so I tried it.

And I’ve tried it five more times since then, and I still can’t bring myself to like it.

Yes, I prefer Facebook.  I like having built-in mechanisms to find my friends.  I like Facebook IM…  Though I’ve only used it a handful of times, it’s smoother than playing tag through email or tweets or other offline messages, but less hassle than having to boot up one of a half-dozen existing IM clients.  And as for those privacy concerns, they’re not my concerns…  My dirty little secrets are few and far between, I have nothing to hide, and I’d like to think I have more sense than to upload the sort of information that could result in identity theft.

But this rant really isn’t about the things I like in Facebook.  It’s really about the things I hate in Twitter:

• It’s ugly.  You would think it would be too simple to be ugly–especially since it uses a down-to-earth font like Arial–but they have found a way to cram every ounce of ugly possible in 140 characters.  I hate “twitter litter”…  The stupid @ symbols prefixing half of all twitterfeeds, the tiny urls, even the stupid o_O googly-eyed default icon…  It’s an icon, it’s a PNG, capable of a millions of beautiful colors, or at least gradients galore!  Why make it look like more text?  Twitterfeeds, IMO, are uglier than MySpace profiles, and that’s saying a lot.  But at least with MySpace, there’s a chance to use your l33t stylesheet skills (or copy-paste ability) to make your profile look not-so-hideous.  I guess the difference is that Twitter is trendy or kinda “scene” despite its rough-hewn appearance–or perhaps because if it–like shopping  at vintage stores or something.
• It’s full of shit.  Literally.  I just asked Trish what she thinks about Twitter, and this was what she told me: “I’m taking a shit now.”  Let me clarify:  I didn’t walk in on her in the bathroom or anything.  That’s how Twitter reads to her.  People seem excited to post details both intimate and mundane…  Every “sneeze, fart, and hiccup.”  Her words, not mine!  But it’s true.  At least make it intimate–and juicy! I cringe at my old LiveJournal entries because they seem so self-absorbed, but at least there’s substance to them.
• It’s too short.  I suppose 140 characters sounds like a lot, but unless you’re rocking Dick & Jane levels of literary prowess, it’s about enough for two sentences, and very little flavor.  (In fact, Trish pointed out, that last sentence alone was too long–170 characters.)  If you’re reading this (or if you’ve given up by now, which I wouldn’t blame you for) you know that I like to rant.  So, if there’s something going on worth writing about, I’m probably going to need more than 140 characters to fill it.  I could be wrong, but it doesn’t seem like Facebook or MySpace have such a conservative limit.  And anyway, how hard would it be to truncate a status message with ellipses?  Plus, this 140-character business is the reason behind the recent popularity of tinyurls, which I loathe.
• It’s spammy.  I follow a whopping three people: two friends, and Leo Laporte.  I listen to Leo’s podcast, This Week in Tech, and like what he has to say.  But his tweets drown out my friends’ posts.  Granted, this can be an issue on Facebook too…  But on Facebook, I can “turn down the volume” on certain types of posts or on particularly spammy friends.
• It doesn’t seem terribly secure.  Again, I’m curious why people tolerate Twitter where they didn’t tolerate MySpace.  Sure, MySpace had plenty of exploits and phishing expeditions, but I never remember reading about an administrative account getting compromised–but Twitter admin accounts have been hacked.  I’m sure a lot of  the other “celebrity hacks” and etc. have been a matter of social engineering, not of technology, but I still blame Twitter.  Twitter more or less relies upon their API allowing third-party clients to provide updates, which gets people too used to typing their passwords into all different apps.  Twitter ought to develop some of their own clients and require third-party clients to go through a user-approval process, on a case-by-case basis, similar to how Facebook apps function.

This week, Facebook is rolling changes to their home page and fan pages, changes that seem targeted at making Facebook a “Twitter killer”.  Bring it on, I say…  Not because I want Facebook to become more like Twitter.  (I needn’t worry about that, Facebook is far too elegant to become like Twitter.)  No, I’d like to see everyone jump ship on Twitter so I can stop hearing about it.

And now, I think I’ll stop talking about it!