I have a few ideas for fixing this problem, but one of them came to me a few months ago as I was using Jason Kottke’s excellent Stellar.io service (pronounced “Ste-LAH-ree-oh” by everyone except Jason). Stellar.io is a fantastic web-based service that lets you follow interesting people and receive a feed of all the tweets, Flickr images, YouTube videos, and other content they have faved on other services. In Twitter terms, imagine a feed that doesn’t contain your friends’ tweets, but rather the tweets that your friends have faved. In other words, one degree of separation away from your current Twitter stream.

Stellar is a great way to assemble this sort of feed, but if you’re like me, you’d rather see its output merged into your existing Twitter stream. To put it differently, when I open up my Twitter client, I want to see tweets from the few people I follow (as I do currently) and tweets from people I don’t follow which have been marked as favorites from people I do follow. Have I lost you yet?

To create this experience, I wrote a PHP script I call Stellar Tweetbot which runs every 5 minutes via a cronjob that checks my Stellar account for new faved tweets, and then retweets any new tweets to my zombie Twitter account @mike_stellar. Then, I follow @mike_stellar from my normal Twitter account @mikeindustries and I magically have a more interesting Twitter stream.

To see what sorts of things now appear in my Twitter feed, without having to follow any new people, peep the image below (or just follow @mike_stellar):

The first tweet is Rob Delaney making sure a can of Pepsi gets home safe. I don’t follow Rob so I would have normally missed this tweet. However, since I follow some people who faved it, I now see it in my Twitter stream.

The second tweet is to a really interesting article tweeted by Rob Pegoraro. I don’t follow Rob, but I do follow the person who faved it: Tim Carmody (not to be confused with Tom Carmony, who I also follow, but let’s not even get into that).

The third tweet is by the funniest person on Twitter, Ken Jennings. Since I already follow him, I won’t see this as a dupe in my feed. Magic.

So that’s it. The Stellar Tweetbot. I’ve opened sourced it on GitHub, and it’s the ugliest designer-written PHP code you’ve likely ever seen, but it works, yo! If you’re one of those propeller heads who writes much better PHP, feel free to rewrite it, and merge it into the GitHub Branch Repository Chamber Fork Commitment Thingamajigger.

Otherwise, feel free to do what I do and just use it. It will make your Twitter feed more interesting.

While the latest version of Mac OS X, Lion, is generally wonderful, there is one “feature” that annoys thousands of people to no end: whenever your machine is restarted, every single application you happen to have open at the time is also relaunched and restored to the state it was in before you restarted. If you restart manually via the “Restart…” menu item, there is a checkbox you can uncheck which is supposed to shut off this behavior but it doesn’t always work. Additionally, if your computer restarts for any other reason — e.g. a power failure or a crash — you don’t even have the option of trying to prevent this behavior.

The downside of the behavior is obvious: it increases the time it takes to start up your machine into a steady state and it re-opens apps you may not be using anymore.

If you want to prevent this behavior entirely, there is now a foolproof, fully reversible way to do it. Simply:

1. Quit all of your apps.
2. Navigate to here: ~/Library/Preferences/ByHost/com.apple.loginwindow.*.plist (whereby * is a bunch of characters)
3. Click the file, do a File > Get Info (or command-I if you’re a pro), and lock it using the Locked checkbox.

Voila. You’ve now prevented Lion from saving what apps and windows are open. To reverse this setting, simply unlock the file!

Another helpful hint as well: Lion, by default, hides your ~/Library/ folder. To make it visible again without showing all of your other invisible files, simply open up Terminal and type:

chflags nohidden ~/Library/

When someone dies, the phrase “there will never be another” gets used quite frequently. It’s one of those phrases that is both always true and yet almost always not true. It’s true that, yes, no other person will ever be exactly like any other person, but it’s usually false in the compliment it’s actually trying to pay.

In almost every case, when a public figure dies, there are plenty of his or her contemporaries ready to fill the void. A great guitarist died? Well we at least have hundreds of other world class guitarists to listen to. A basketball star died? Luckily we have plenty of those too.

The truth of the matter is that even best of the best in most fields, at any given time, is only a little better than the rest.

Counterexamples to this seem to happen only a handful of times per century. The number of times we lose someone whose impact was so dramatic and whose substitute seems so unfathomable is vanishingly small.

We lost that person yesterday in Steve Jobs, and we are only beginning to feel the impact of his absence.

What gets lost in all of these Steve Jobs tributes you read online is just how dark things were for personal technology only ten years ago. People forget that until the iPhone came out, “The Apple Way” was still largely on the sidelines. Windows PCs were unavoidable. Cell phones were unapproachable. There were even a few years around the turn of the century when many websites didn’t even work on Macs because developers only coded to PC Internet Explorer “standards” (airiest of air quotes there, of course).

It was just dark as hell out there; especially for those of us who wanted so badly for the story to end differently. The lesson that idealism and attention to detail could lose out to “good enough and a little cheaper” was not something we wanted to learn.

The long, but impeccably planned, turnaround that Steve Jobs has led over the last 14 years is impressive for thousands of reasons. None is more astounding to me than this one though: he was quite literally the one person on the face of the earth capable of pulling it off.

One. Out of 6,800,000,000 people.

He wasn’t just the best choice. He was the only choice. And that’s why we’ll miss him so much.

When people die after suffering from prolonged illness or pain, my thoughts are almost always positive. Death is not something I fear, and when it’s ultimately the relief method for someone’s pain and suffering, I feel happy for their newfound peace. I felt this way when Kurt Cobain died, for instance.

With Steve Jobs, however, I don’t get the feeling death was any sort of relief at all. Yes he was obviously at peace with the concept, as he expressed beautifully in his Stanford commencement speech, but SJ put the pedal to the metal until his final breath.

What would you do if you knew you had a short time to live? Most of us would quit our jobs. Many of us would travel. Some of us would relax and keep our stress levels down. What did Steve do? He hit the gas. He released the iPhone, unveiled the iPad, and led Apple to its current and still unfathomable status as the most valuable company in the world.

Just as incredibly, he was able to lift his body out of Apple without also removing his soul; on a day when many once feared AAPL stock would dive precipitously, it’s comfortably unchanged from the day before.

He had his flaws and he may not be the greatest person to ever live, but no one has ever left this world more on top than Steve Jobs has just left it.

Thanks for everything.

It’s interesting to me that Happy Cog is trying to eliminate the negative things associated with commenting by encouraging brevity, while for several years, the secret sauce I’ve cooked up to prevent comment spam has involved just the opposite: measuring the amount of time you spend typing and only entering your comment into the database if you spend more than a few seconds on it. It works like a charm and eliminates 99.9% of comment spam before it even gets in the front door.

In my opinion, what Happy Cog has created is useful. Let’s just not confuse it with a commenting system for a blog.

It doesn’t encourage community, it doesn’t encourage conversation, and for the most part, it’s not accretive in any way. What it does do is create a lot of linkbacks to your blog on Twitter. Is this valuable? Sure. But is it as valuable as free-flowing, insightful, conversations which elevate ordinary posts into conversation pieces?

Not for me it’s not.

For all the great things about Twitter — and there are many — one of the worst things about it is that it’s making us lazy ambassadors of our thoughts. Why spend an hour on a blog post when we can tweet out our main thesis in ten seconds? Why allow conversations on our blogs when we can just hear the first 140 characters of our readers’ opinions?

We know short attention spans are bad for our intellectual development. We should be creating solutions that fight against this threat… not feed into it.

For many years, I’ve railed against tricks like pagination and “jump pages” as a means to goose pageviews. Honest people in the industry will tell you these are simply acceptable tricks to bump revenue a bit, while disingenuous or uninformed people will use “readability” as an excuse to make users click ten times to read ten parts of a single story. For this latest redesign, msnbc.com has decided to de-emphasize page views entirely and present stories in a manner that maximizes enjoyment and as a result, total time on site.

What do I mean by this?

Think of how a typical user session works on most news sites these days. A user loads an article (1 pageview), pops open a slideshow (1 pageview), flips through 30 slides of an HTML-based slideshow (30 pageviews). That’s 32 pageviews and a lot of extraneous downloading and page refreshing.

On new msnbc.com story pages, the above sequence would register one pageview: the initial one. The rest of the interactions occur within the page itself. Can msnbc.com serve ad impressions against in-page interactions? Sure, and that’s key to the strategy, but as a user, your experience is much smoother, and as an advertiser, the impressions you purchase are almost guaranteed to come across human eyes since your ads are only loaded upon user interaction.

This is the first time (to my knowledge) this sort of model has been deployed on a major media site with over a billion pageviews a month, and it has the potential to change the entire industry if it works. It’s also a big risk, as most advertisers are not used to thinking of inventory this way. We like big risks with big payoffs though and we feel that when you take care of the user and the advertiser at the same time, you’re probably onto something.

Ad model aside, there are also tons of other interesting things about the new msnbc.com story pages:

• Every form of storytelling (text, video, audio, slideshows, discussion, voting, and more) is now available right within each story page itself.
• The top navigation (nicknamed “the upscroll”) contains all basic elements when a page loads but if you scroll the page upward past its initial position, you get more interesting stories to read. It’s a great way of presenting a content-packed header without sacrificing screen real estate.
• A social bar at the bottom of the screen, powered by Newsvine, which lets you easier share content via Newsvine, Facebook, Twitter, and other services.
• An “annotated scrollbar” down the right side of the screen capable of teleporting you to any section of the page you desire.
• Bigger, easier to read text. Goodbye Arial, once and for all!

To be clear, the msnbc.com team is very proud of what’s been launched so far, but is under no illusions that things are perfect yet. Everyone involved in creating these new story pages is monitoring reaction closely and ready to modify anything that needs improvement. Since we have plenty of thoughtful design and development voices here on Mike Industries, I’d love to open this thread up for some reactions. What is working for you, and what, if anything, would you change? The team is listening.

Scott’s a great designer, obviously, but hearing about the care that’s going into just the production of the book is going to make this piece of art a must-have. I may even order two and keep one suspended in formaldehyde.

While ordering the book, one part of the process stuck out to me as something I’d never seen before, even having ordered probably a thousand items online in the past: when I typed in my credit card number, a green checkmark showed up immediately after the last digit was entered. My immediate suspicion was that they were counting digits and gave me a check to indicate I had typed in enough of them, but again, having never seen that before, my interest was piqued. I tried deleting the last digit and replacing it with a 1, then a 2, then a 3, and so on. Only when I typed the actual digit from the credit card did I get the green checkmark again.

Further investigation revealed that no server calls were being made, which means this was some sort client-side algorithm that verified credit card patterns. Iiiiiiiiiinteresting!. Even more investigation revealed that this was the work of something I’d never heard of: The Luhn Algorithm.

The Luhn Algorithm is a formula which can be run in javascript, PHP, and most other programming languages that uses some mathematical rules to determine if a credit card number is likely to be valid. Apparently, credit card companies issue numbers according to this algorithm, and if a number doesn’t fit it, it’s definitely not valid. Before you say to yourself “wow, that’s some neat, new technology I can use!”, note that the Luhn Algorithm has been around since 1954!

Although using this algorithm in your own projects is clearly not a necessity, I see a couple of potential advantages and a couple of potential disadvantages:

Advantages

• Instant UI feedback is a great tool to help users correct errors
• The checkmark is a nice bit of instant emotional validation to make sure users complete the process

Disadvantages

• Is there a guarantee that every card will always follow this pattern? What happens if one or many stop following it?
• Since it’s an unusual experience, does it add a bit of suspicion in some users? Would a less technical user assume their number was being broadcast across the internet more times than necessary?

I’m curious to see if this catches on as a trend.

Minertia is what I might call it… short for a “minimal level of inertia”.

Many companies have succeeded primarily because their products overcome minertia. Twitter is a good example of this. There were millions of people with (purportedly entertaining) thoughts, but none of these thoughts were worth spending more than 30 seconds to publish. Twitter provided a way to turn these idle thoughts into legitimate published communication with 30 seconds of effort, and BAM, they are the hottest company on the internet.

On to more pedestrian matters though: recording stuff on TV.

I’ll use Tivo as an example because that’s what I have, but this could apply to any DVR, Apple TV, Boxee, etc etc:

Here is how I decide to add a show to the repertoire of things my Tivo records automatically:

1. Read about a new show somewhere online.
2. Hear or read about it again somewhere else.
3. Read about how good it is again and finally decide to do something about it.
4. If I’m home, turn on the TV, navigate somewhat laboriously through on-screen menus and search for the show in order to set up automatic recording. If I’m away, go to Tivo.com and use their totally crappy search feature, try to find the program, and if that is even successful, set up automatic recording.

As you can see, this sometimes equates to several minutes of work (I’ve spent over 15 minutes trying to do this on my iPhone). Again, we’re not talking about a huge time investment here, but it’s enough to require steps 1-3 whereas with a little minertia reduction, people might be willing to record shows the first time they hear about them.

What got me thinking about this was an interview with Rex I read yesterday. In it, he mentions Modern Family as the best show on TV right now (I say it’s Dexter or Million Dollar Listing, but whatever). Thankfully, Rex’s interview was about the third time I’d heard this so I bucked up and did step 4. But here’s how much easier it could be:

1. Read article on web which contains the name of a TV show.
2. Click a bookmarklet to query Tivo, and Tivo spiders the page, highlighting all TV shows it recognizes.
3. Click on the show you want, confirm with a little ajaxed-in dialog box, and a command gets sent to your Tivo to create a Season Pass for the show.

The effort would thusly be reduced to under 10 seconds.

As with the wine example, I fully expect someone to leave a comment pointing me to something that “kinda sorta” does this, but not in as optimal of a manner as I described above. Anybody know of something that does this? Or better yet, anyone work at Tivo and want to build this? :)

As co-founder and CEO of Newsvine, I can tell you that this is a great place to work and retains the best aspects of a startup atmosphere while inheriting the equally great aspects of working for an established media organization like msnbc.com. If you’re interested in joining the crew, please read the job description below and send your stuff to msnbcjobs@msnbc.com. One caveat, however: We are specifically looking for someone who is passionate about writing code. Javascript, PHP, HTML, etc. This is not a design position and the only UI work involved will be on the implementation side, from a coding perspective.

Job description

The Newsvine Team is looking for an experienced, self-motivated, and passionate front-end developer to join us in building products and services on the Newsvine platform. Your primary responsibility will be to design and develop site features and functionality in a multi-tier web environment using PHP, CSS, JavaScript, and the YUI JavaScript library. Additional responsibilities include daily site support and maintenance. The ideal candidate is able to work on small teams under tight deadlines with little supervision. A computer science degree or equivalent is a plus, but experience, skill, and attention to detail are more important.

The ideal candidate will have a strong command of the following knowledge areas:

• X/HTML, CSS, DOM, and JavaScript
• PHP or similar scripting language
• Mastery of web standards and cross-browser compatibility

Preferable Job Qualifications:

• Experience working on large-scale, high-availability web sites
• Successful industry experience using latest DHTML and ajax technologies
• Experience with SQL and relational database implementations serving as the backend to production web applications
• Experience with, or an interest in, working with the YUI JavaScript library
• Familiarity with Subversion a plus

As a co-inventor of sIFR, I’ve been getting a lot of emails this week asking what I think of this new effort. In evaluating its promise, it’s important to examine the following characteristics, in order of importance: compatibility, functionality, legality, ease of use, and hackiness.

Compatibility

Compatibility is the most important aspect of any new web technology. If your shiny new method only works in 10% of web browsers, it’s nothing more than a proof-of-concept. It is this reality check that keeps me from getting excited about W3C meetings, Internet Explorer extensions, or anything else that doesn’t apply all browsers in the here and now… or at least the right around the corner.

Compatibility was also what pushed sIFR over the top in terms of popularity, working in over 90% of all systems and falling back gracefully in most others. It also came out at a time, 2004, when there wasn’t a whole lot of tolerance for leaving certain browsers behind or having things look ideal in a few browsers and not so ideal in others.

Typekit appears to be doing ok on the compatibility front, targeting current versions of Safari, Chrome, and Opera natively, the next version of Firefox (3.1) natively, and all versions of Internet Explorer via a “backup” EOT solution. Here’s what the browser share landscape looks like today:

• Works in:
  • Internet Explorer: 66.1%
  • Safari: 8.21%
  • Chrome: 1.42%
  • Opera: 0.68%
  • Firefox 3.1 or greater: 0.18%
• Doesn’t work in:
  • Firefox 3.0 or lower: 22.3%
  • Miscellaneous other browsers: 1.11%

So you can see right off the bat that Typekit will work in just over 76% of browsers. Not quite as high as some of the methods that came before it, but it’s extremely important to recognize that the one group that’s keeping Typekit from almost universal compatibility is Firefox. I have no evidence to support this, but I imagine that Firefox users are among the quickest to upgrade, which would seem to suggest that this compatibility gap could be closed relatively quickly. Data shows that Firefox 3 is already used by 11 times more people than Firefox 2, and considering it was released just short of a year ago, this sort of upgrade pattern is encouraging.

Given the above data, combined with how often Firefox seems to annoy me these days with upgrade notices, I expect Firefox 3.1 or greater to be the dominant Firefox version in use one year from now, thus pushing Typekit’s compatibility percentage into the upper 90s fairly soon.

It’s also important to praise what Small Batch has done here on the compatibility front: their killer concept was involving type foundries in web-only licensing and propagating the font files through the standards-complaint @font-face CSS declaration, but they realized their solution would be academic if it didn’t work in Internet Explorer, so they made sure their backup implementation using EOT files took care of all IE users. The lack of this sort of practical thinking is what keeps a lot of great ideas from gaining traction on the web.

I also think that designers these days, self included, are a lot more amenable to things looking great on “most systems” as long as they at least work reasonably on other systems (as long as they look great on the particular system the designer uses). This is a bit of designer bias, of course, but it also represents an increasing desire in the design and development community to leave the old web behind. I still remember how much crap I took at ESPN from validatorians when we decided to leave Netscape 4 — with its 1% marketshare — behind. Now it’s all the rage… and I love it!

Functionality

By all accounts, Typekit will be more functional than any method that came before it. This is quite obviously because it uses a browser’s native font rendering technology. There are some concerns about reliability gaps stemming from downloading fonts off third-party servers, but I believe this fear will prove unfounded. Additionally, I imagine both the @font-face and EOT versions of fonts will come in larger files than sIFR font files (because usually you only embed a subset of characters in a sIFR font file) but with broadband penetration being what it is today, this too will prove immaterial. Additionally, even though sIFR font files may be smaller, the noticeable delay in rendering them probably more than makes up the difference.

Legality

I put legality in the middle of the pack and not at the top because, to my knowledge, there haven’t been any serious legal dust-ups over the use of technologies like sIFR and Cufon. So far, the burden has been on designers to buy the fonts they use before embedding them using sIFR or Cufon, but at the same time, there’s been no clear blessing or condemnation of this practice by foundries or type designers.

The nice thing about Typekit is that it specifically involves foundries and type designers in the process of licensing their fonts for use on the web. When you use Typekit, you know with certainty that what you’re doing has the direct blessing of the people who created and/or marketed the typeface you’re using. This is a nice piece-of-mind upgrade as well as a way of further compensating type designers for giving us the building blocks of web design.

Ease of use

Typekit promises to be easier to implement than either sIFR, Cufon, or any other font replacement technology. I guess we won’t know until we start using it, but it would shock me if it took more than a few minutes to implement, including licensing the font you want to use. sIFR’s second most common complaint other than “it uses Flash and Flash kills puppies” is that it’s a bit difficult to implement. Typekit’s improvement on this front will be more than welcome.

Hackiness

First let me say something I’ve said many times before: the entire world wide web is a hack. Get over it. Secondly, however, any technologies or methods — that work — which serve to dehackify it a bit are welcome. Typekit certainly dehackifies custom typography on the web by leaps and bounds. It was the solution we all knew would come eventually when we created sIFR as a stopgap five years ago. Just about the only things hacky about it are that it falls back to EOT (which, as discussed earlier, is great) and that it uses Javascript to handle the licensing nuts and bolts (meh, big deal).

Conclusion

Typekit is likely the best thing to happen to web design since the re-emergence of browser competitiveness. It will be embraced quickly and fervently when it is released this summer, and its creators should be loudly applauded for doing it instead of just talking about it. There are too many talkers in the world and not enough doers. The team at Small Batch has done an excellent job of taking a problem that a lot of people like to talk about and solving it in a practical, equitable way. It’s a welcome solution to a real issue and a significant step towards a leaner, Veener web.

My side was as follows: All web editors — including TinyMCE, YUI, and FCKEditor — are broken in different ways, and the only software I’ve seen which can satisfactorily desuckify one of them is WordPress. Because of that, we should deconstruct what WordPress has done to TinyMCE and apply the same duct tape to our own editor on Newsvine (we use TinyMCE currently, but are in the process of moving to YUI).

Our development staff’s side was as follows: All web editors — including TinyMCE, YUI, and FCKEditor — are broken in different ways, and because of the crazy amount of ridiculous cleaning, converting, regexing, transforming, and other shenanigans WordPress has to do to their editor just to get it to the state it’s in right now, it’s not worth spending the time to recreate such a mess, only to have it remain imperfect and possibly break in upcoming browser releases.

There are several things wrong with each editor but the particular problem we are trying to solve is that when you’re in HTML mode, you can’t create paragraphs just by putting double newlines between them. Some people say that because you’re in HTML mode, you shouldn’t expect an editor to do this for you, but I’ve been using blog software for six or seven years and that is the behavior I — and I believe most others — are accustomed to, so I couldn’t imagine releasing something without it. As mentioned above, the WordPress team has craftily hacked this functionality into their WYSIWYG system, but other platforms like Typepad have not.

I could go on and on for another hour about details, but after going through all of the WYSIWYG editor machinations we’ve gone through, I’m left wondering why the web development world still hasn’t figured this out yet. We can write an entire e-mail application, a replacement for Excel, and whatever the hell these things are, but we can’t replicate a toolset we’ve had in MacWrite since 1984?

Think of how much has happened in the last 25 years, and we haven’t been able to nail that.

TinyMCE circa 2009: Millions and millions crrrrrrrrazy features. Doesn’t work satisfactorily.

Microsoft Word circa 1991: Just enough features. Works plenty fine for most people.

I know hard-core coders like to hand-code html even when writing web comments (self included), but 90% of the world would rather not be bothered with that. What’s it going to take for this problem to go away? If you’re involved in WYSIWYG editor development, I’d love to know. Is it the disappearance of old browsers? Is it something that should be Flash-based? Is it just that no one’s really worked full-time on the problem yet? Why isn’t WordPress’s crazy hackery built into TinyMCE in the first place? So many questions…

So far, the one effort I’ve noticed that seems to take the cleanest possible approach is the WYSIWYM Editor. What-You-See-Is-What-You-Mean essentially translates to “the HTML code associated with what users type will semantically match what they intend”. Meaning, if I type two blocks of text separated by a double newline, I get two properly <p>d paragraphs out of that… not just a blob of text separated by <br> tags. Or if I bold some text, I get <strong> tags instead of other ridiculousness.

Sadly, the WYSIWYM Editor seems to have been in development since 2006 and is only at 0.5b, but happily, there appears to be a healthy flurry of activity around it lately. I really don’t mean to disparage the hard work that’s gone into all of these imperfect WYSIWYG editors in the past, and I do realize that browsers are the core culprits here, but it’s 2009 already and I’d prefer a solution to this longstanding real-world problem over almost anything promised in HTML 5, CSS 3, or any of the other specs we’ve been eagering awaiting for the last several years.

One service that’s caught my eye recently is the increasingly popular Tumblr. I have friends who run their main blogs off of it and others who just run one of their multiple blogs off of it. I still like hosting my own WordPress blog and would never outsource this to a hosted service, but at the same time, running all linkblogging activity through a service like Tumblr sounds appealing — especially considering I can then pull all of that activity into my main blog using something like WP-O-Matic.

The super nice thing about Tumblr is how simple the posting interface is. The “Share on Tumblr” bookmarklet the company provides does a pretty good job of automatically figuring out what type of content you’re posting and treating it accordingly. In other words, if you seed from a YouTube page, the link gets posted as type “video” and is displayed accordingly. These sorts of interface niceties reduce the amount of work required to save links and thus encourage more linking activity. Both good things. The woefully inadequate “Press This” bookmarklet from WordPress just doesn’t measure up.

So… a couple of days ago when I decided I wanted to migrate all of my Del.icio.us bookmarks over to Tumblr, I couldn’t for the life of me find an automated way to do it. Tumblr has an import feeds feature but it is misleadingly named. It doesn’t actually import existing feeds. It only adds your feed URL and then posts any new items you add afterwards. This does nothing to aid in the migration of existing content over to Tumblr.

Using a combination of the Tumblr API sample code and some code I stole from Greg Neustaetter, I created a PHP script which imports all of your existing Del.icio.us bookmarkets into Tumblr.

Warning: I am not a PHP genius so I know the code isn’t pretty… but it works. It imported all 312 of my Del.icio.us bookmarks in under a minute.

In case you’re interested, here’s how to do it (caveat — you might want to do this on a fresh Tumblr account, just to be sure):

1. Log into your Del.icio.us account.
2. Hit http://del.icio.us/api/posts/all and save the file to your desktop as “delicious.xml”. Upload this file to your server.
3. Upload Delicious-To-Tumblr.php to the same location on your server and edit the two lines in the file specifying your Tumblr email and password (to authenticate with the Tumblr API).
4. Hit Delicious-To-Tumblr.php in your web browser and all of your entries will be imported.

Voila! Del.icio.us-to-Tumblr migration in about a minute. Enjoy.

First the standard caveat: designing a major media site is not as easy as it may appear. It is not like designing a blog and not like designing a standard “web presence” for a company. There are hundreds of internal stakeholders to answer to, millions of daily users to please, and a ton of legacy and third-party code that is often outside your control. Anyone who tries to knock down the virtues of a major media site redesign based on how far it falls short of perfection is making the wrong comparison. The most important benchmark to grade is simply the amount of improvement (or worsening) from the last iteration of the site. Secondarily, comparison against competitors is also very important.

First things first, there’s a lot to like about the redesign:

Cleanliness

In my five years at ESPN, there was always a lot of push and pull between design cleanliness and information density. On the design side, we always fought for an economy of elements on the page. Big striking headlines, well placed lead-ins, content modules here and there, but nothing to overload the screen. On the editorial and business side, there was always a push for more video, more features, and just generally more content all over the place. The ideal philosophy is of course somewhere in the middle, but over the last few years, I feel like ESPN had gone a bit too far in the “Times Square Billboard” direction, with too much visual distraction (especially in the form of autoplay video).

The new redesign gracefully chisels away a lot of the visual clutter and presents a calmer, gentler ESPN for your perusing pleasure. Gone is the autoplay video and other visual cruft that had built up over the years.

Note: When I refer to “visual cruft”, this is a phenomenon that happens to every content site over time. Essentially, you redesign and everything’s perfect, and then “plaque” kind of builds up over time in the form of code and design elements that are inserted to meet editorial or business needs. Each redesign is an opportunity to chisel off the plaque and start anew.

Code Quality

Don’t even bother trying to run the ESPN front page through the stupid W3C validator because that’s a lousy way to judge code quality. The tomato-throwers among us will of course do this immediately and point to the hundreds of validation errors as evidence of incompetence. The more seasoned among us know that 500 ampersand-related errors are meaningless in the grand scheme of things and we wish the validator could be configured to selectively mute certain types of benign errors.

The HTML for the front page is a svelte 22.8k gzipped (73.4k unzipped) and the code is pretty well written. All CSS for layout — natch — and decently structured HTML.

I will not comment on accessibility because I am not an accessibility expert. I’ve long railed against judging a site’s true accessibility by looking for alt text and well structured code, as I simply don’t believe those elements — on their face — make a site accessible or not. A site is accessible if observed user behavior suggests that disabled people can use the site with reasonable ease. If you don’t know how disabled people actually use your site, you have no idea if it’s actually accessible. Period. You may have followed best practices to improve its accessibility, but you just don’t know if it passes the test unless you test.

That said, I have no idea how accessible the new ESPN.com is in the real world. I imagine it’s ok, but certainly not perfect.

New Story Pages

I don’t have a whole lot of objective things to say about the new story pages, but they look cleaner than the previous incarnation. Very readable, very uncluttered, and good video integration where appropriate.

Navigation

ESPN moved to top navigation a few years ago and they’ve never looked back. I’ve long preached the benefits of putting your main navigation across the top of the screen and ESPN has fine-tuned their implementation with this release. Good rollovers, good information architecture, and just all-around snappy. I’d like to see msnbc.com move to top navigation with their next redesign.

Video

As mentioned above, gone is the awful autoplay video. In its place is a video tab which is a lot more polite to users. I don’t think many users will click on the video tab (because in general, no one clicks on tabs), but I do think when ESPN has great video, they’ll probably flip to “video mode” automatically… and I’m totally cool with that, as long as it doesn’t autoplay.

But it’s not all roses with the redesign. I do have some issues with it:

Below the Fold

By far the worst thing about the redesign is the ghettoization of the below-the-fold area on the home page. It’s tragically uninteresting. When I was working on the 2003 redesign, I remember John Skipper (rightfully) making a big deal about how important the below-the-fold area of the front page was and how we needed to make better use of it. The last redesign had a nice Flash feature slideshow thing going on and that is now gone, in favor of the gigantic heads of ESPN columnists. I love ESPN columnists, but their headshots add absolutely nothing to their stories. It’s a huge waste of space and it’s subconsciously a very unattractive area to scroll to.

Because of this, the new ESPN frontpage is now more of a “glance and go” site for me now. I don’t want to scroll because I have no confidence that there is anything worth scrolling to. Compare that to, for instance, the msnbc.com frontpage, where there are a ton of things to keep you interested all the way to the bottom of the page. I actually think msnbc.com is among the best in the industry at this.

One thing ESPN did to encourage people to scroll is put the main headline in the bottom area of the main marquee. Sorry, my screen’s big enough to still see it anyway. Not going to scroll.

Tinting Red is Dangerous

Unless your site caters to females, it’s always risky to tint your reds. Even the slightest tinge of pink on a site like ESPN can ruin the whole look. Generally ESPN has gone with shades of red (red plus black) or maintained very clear boundaries between reds and whites. With this redesign, there is a pretty noticeable gradient from red to light gray, and while it’s clear they limited the pink zone by using a steep gradient, it’s still noticeable.

Minimal Customization

I don’t see a whole lot of customization options besides the “My Headlines” tab. It’s very hard to do customization well, but this strikes me as not much of an effort at all.

Conclusion

All in all, I think it’s a nice redesign. Not one that knocks you on your ass and wows you to your core, but tasteful nonetheless. I found myself visiting competitive sites like Yahoo Sports, CNNSI, Sportsline, and Fox Sports to compare this against their latest versions, and after thinking about it, I still think ESPN’s design compares favorably to all comers.

The first question to answer in this redesign is: what are the discrete types of content I will be posting once the redesign is complete. So far, this is what I’ve come up with –

1. Web design and development articles
2. Other articles
3. Product Recommendations
4. Random links of interest, a la what’s in my sidebar right now
5. Newsvine seeds linking to interesting news stories I’ve read lately
6. Photos
7. Videos
8. Links to latest entries on A House By The Park
9. Latest Twitter posts

The items are more or less in order of what I think people would be interested in. The first three would be full text posts and the rest would be in some sort of compact form, either inline with the rest of the posts or more likely in a sidebar.

So far so good. I’m pretty confident I can pull all of that off with not too much work. The problem, however, is how that all manifests in an RSS feed. WordPress has a great feature where you can mix and match categories into different RSS feeds — which I fully plan to do — but what goes in the default feed? That is the $64,000 question. With somewhere between 5,000 and 10,000 subscribers, I don’t want to piss anybody off by shoving a lot more updates in there to relatively meaningless things like Twitter entries. As a reader, I prefer to subscribe to RSS feeds that update once or twice a week max and if one of my favorite blogs shoved the whole kitchen sink into their feed suddenly, I might unsubscribe.

On the other hand, however, I’ve had plenty of people say things to me like “I used to always read your blog… back when you updated it!” — clearly implying that 2 or 3 updates a month isn’t cutting it.

So the first question to answer is “what should go in the default feed?” If you’re a current Mike Industries RSS subscriber, please vote in the poll to the right.

The second question is not really something I need votes on, but perhaps should be discussed in the comments below: when offering custom RSS feeds, is the best practice to create them by opting out of categories or opting in? Here are the two ways you can custom feeds in WordPress –

http://www.example.com/feed?cat=1,2,3

(Returns a feed with items from categories 1, 2, and 3)

or

http://www.example.com/feed?cat=-4,-5,-6

(Returns a feed with all items except from categories 4, 5, and 6)

The user interface for creating each style of feed can still be identical (a bunch of checkboxes), but the nature of the subscription is subtly different. Let’s say you’re subscribed to the first feed and I add a 7th category. Say category 7 is links to a third blog that is created at some time in the future. If you’re subscribed to the first feed, you won’t get the new stuff. If you’re subscribed to the second feed, however, you will, because you haven’t specifically excluded category 7. There are advantages and disadvantages to each. If you have any insight into this or any other related issue, I would love to hear your comments below.

“I am a huge proponent of preservation on the web. If and when I redesign, I will archive this version like I did with my last. I think it’s important to keep content and design paired together when possible. That’s where the context and meaning live.”

I agree with Jason and his reasoning is part of why I haven’t redesigned Mike Industries since launching it almost five years ago: I don’t like the idea of changing the visual context of past entries or having to make a new design backwards-compatible, especially with with some of the more visually complex entries that have appeared from time to time.

While I like Jason’s idea of archiving entire versions of his old sites at different subdomains, I think I’d actually rather just set a cut-off date whereby every blog post older than that date uses the old theme and every other page or post on the site uses a new theme. In searching around, I can’t find a way to do this in WordPress. It seems like something that could be the basis for a very useful plug-in. Call it “WP Non-Destructive Redesign” maybe.

Any WordPress hotshots out there know how something like this could be accomplished? For the quick and dirty version, ideally you’d first officially switch to a new theme and then there would be one setting in the plug-in’s options which would let you specify a cut-off date and a theme name to apply to the old stuff.