Mike Industries

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.

I was looking forward to writing a post this weekend about Happy Cog’s new commenting system on their otherwise excellent new blog, but the sage minds at Full Stop interactive beat me to it. You should read Nate’s whole post. It’s spot-on.

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.

This weekend, msnbc.com launched a sweeping redesign of the most important part of their site: the story page. The result is something unlike anything any other major news site is offering and is a bold step in a direction no competitor has gone down (yet): the elimination of pageviews as a primary metric.

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.

I finally put in my pre-order for SimpleScott’s Designing Obama book a few minutes ago. I wanted to buy it earlier but never overcame the inertia until I got a chance to have beers with Scott and then listen to him speak at the excellent Webstock conference in New Zealand last week (by the way, thanks to Khoi Vinh for asking me to step in for him as a speaker). Can I also just say that Webstock is the best designed conference I’ve ever seen?

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.

Lately I’ve been intrigued by situations in which the amount of effort required to complete a task is not overwhelming but it is enough to prevent the task from getting done. The latest example, from a couple of weeks ago, was wine journaling. Sure it only takes a few minutes to pull out a laptop, log into your wine-dot-whatever account and structure a proper review, but unless a few minutes becomes a few seconds, I’m out… and so are thousands of other people.

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? :)

There’s no better place to be during an economic downturn than a solid, profitable company with a long track record of success. Come to think of it, there’s no better place to be during an economic boom than that sort of place either. Msnbc.com, proud parent of Newsvine, is just that sort of place. The most visited news site in the United States for the past 12 months and running, msnbc.com is hitting on all cylinders and is expanding the Newsvine team by one talented web developer.

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

Last week brought word of a promising new type solution for the web called Typekit. Created by Jeff Veen and the smart folks at Small Batch, Typekit aims to solve the problem of custom typography on the web once and for all. Unlike sIFR, Cufon, and several other stopgaps before it, Typekit does not attempt to hack around the problem, but to solve it in a permanent way, which is exciting.

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.

We got into a heated discussion in the office about WYSIWYG web editors today. While heated discussions are nothing new to us, neither side even being happy with their own argument was. When people are arguing over things they don’t even believe in, there can be no positive outcome.

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.

I’ve been using Del.icio.us, the fabulous Joshua Schachter creation, as my linkrolling tool for a few years now. Although it can be a powerful tool for organizing and browsing through interesting URLs, I find I only use it for two things: saving links and displaying said links in the sidebar of Mike Industries. For that reason, there are probably any number of bookmarking services which would amply serve my meager needs.

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.