When I noticed it broke, I spent several hours trying to figure out why and to fix it as quickly and easily as possible. Essentially, there are two reasons why it doesn’t work anymore:

1. PHP 7 no longer lets you use "=&" to “assign a new object by reference”. I don’t even really know what this means, but I do know you can solve it simply by removing the &. There is only one place you need to do this in Mint’s code and that is on line 3409 of /mint/app/lib/mint.php where it says $DOM =& new SI_Dom($xml);. This problem was infuriating because it just makes the whole app fail silently, without throwing a single error. I spent a half a day deleting random code just to identify the culprit.
2. The MySQL API has been deprecated in PHP 7 and Mint uses it for all of its database work. You’re supposed to rewrite all of your queries to use the new mysqli or PDO_MySQL APIs, but after a few hours of trying to do this, I realized my PHP skills were not up to the task and I opted for an easier solution instead. There’s a wrapper you can just include with your Mint install that translates all of the functions on the fly for you. This method is generally “not recommended” by people who actually know what they’re doing, but for a quick fix, it worked perfectly for me. If someone wants to patch Mint correctly, I will gladly post a pointer to it here. Anyway, all you have to do is download that file, upload it to /mint/app/ (next to path.php), call it something like mysql_bridge.php and then add this line right above the first include statement in /mint/index.php: include(MINT_ROOT.'app/mysql_bridge.php');

Voila! You’re done. The whole procedure should take only a few minutes.

“When is this going to ship?”

“Real artists ship.”

The verb “ship” has a long history in the software development world and before that, the physical world. In the physical world, it originally meant “to transport something on a vessel”, and in the software world, it meant “to press a tape/disk/CD and send it out to consumers”. Since then, it has come to simply mean “release”, and even then, usually not in any sort of final form.

Everyone inside tech companies loves shipping. It’s the culmination of a lot of hard work and creativity from designers, engineers, PMs, researchers, and any number of other people, and when it’s good it puts a dent in the universe. It is no wonder then that so much of the machinery of tech organizations is centered around shipping.

But should it be? Especially given how much shipping itself has changed in the last couple of decades?

Here is a non-exhaustive list of problems that can occur when everything is oriented around shipping:

• Teams ship inferior or non-impactful things in order to say they shipped something
• Team A ships more than Team B and thus appears more competent, even though Team B’s mission is more difficult or process more rigorous
• Teams ship things that teach their company nothing
• Teams manipulate (or very liberally analyze) data in order to justify shipping
• Teams aren’t given enough runway to do great work because of the constant pressure to ship ASAP
• Team members are given (or not given) raises, promotions, or other praise because of how often (or seldom) they ship

Whenever I talk to design leaders from other organizations, I’m struck by how similar everyone’s challenges are. Over coffee with my friend Cap Watkins — Buzzfeed’s Head of Design — we talked about if there was a better way to measure progress than shipping.

Learning as a prime objective was what kept coming up. Organizations that learn the quickest seem the most likely to succeed over the long haul. This is not an original thought, for sure, but most companies don’t seem to have operationalized it formally.

Maybe shipping is actually just a subset of learning, or at the very least, in service of it. Put differently, shipping can be a great way to learn, but it’s not the only way, and it’s not always the best way. If all of that is true, how might we re-orient the development process around learning?

A provocative approach would be to prioritize learning as the most important regular deliverable of engineering/product/design teams. Let’s say you are a manager, executive, or anyone else interested in a particular product within a company. Here is the sort of progress report you are probably used to seeing from whoever is leading the team building the thing:

SEPTEMBER

• Launched movie recommendations
• Hired 2 engineers
• Fixed 30 bugs
• Went into beta with collaborative filtering
• Drafted product plan for internationalization

When written more with more structure, they can take the form of OKRs (Objectives & Key Results) or KPIs (Key Performance Indicators).

While useful in showing that the team isn’t sitting on their hands, it doesn’t really hold anyone accountable for what good all of that is doing for the organization. What caused the team to launch movie recommendations and what will that mean for the business? What will 2 more engineers accomplish? What is the impact of the bugs fixed? What do we hope to learn from the collaborative filtering beta and how will we know we should even launch it? What have we learned about internationalization in terms of how much bigger it will make our business or how much of an effort it will be?

A list like the one above is at best a tactical inventory, but at worst a veil that masks how little actual learning may be occurring. In other words, it may make you look like you’re moving forward (good!) at the expense of ignoring how little of a difference you are making (bad!). What if, instead of delivering something like that every week, month, or quarter, you delivered something more like this:

SEPTEMBER

• What we learned: Removing steps from our onboarding experience did not reduce user confusion. Instead, clearing up language such that users felt they were making progress resulted in the greatest gains (link to more details here).
• Cost to learn: One researcher, one prototyper, one week of calendar time, and $2000 in participant fees.
• Plan to proceed: Productionize new language within one month.
• What’s needed to proceed: Some internationalization help… we’ll outsource this.

 

• What we learned: We have entire tab in our app — Theaters — that only 1% of our users regularly use. Additionally, we have another feature — Friends — buried under a sub-menu, that almost half of our users use regularly. We aren’t sure what the effects would be if replace Theaters with Friends, but it seems like the right thing to do.
• Cost to learn: One PM, from one day of digging through data.
• Plan to proceed: Run an experiment swapping in a Friends tab in place of the Theaters tab and see what effect it has on metrics.
• What’s needed to proceed: We have no dedicated data scientist in our group. Would be great to have one, but short of that, if we could just get a day per week of someone’s time, we’d take that.

 

• What we learned: Our projects take at least 30% longer than they should because of an outdated build process that has too many dependencies. In addition to the cost in extra time spent, we have also lost engineers and designers due to this frustration.
• Cost to learn: We’ve been paying this cost in slow development and high attrition for at least two years.
• Plan to proceed: We just dedicated two weeks of an engineer’s time to investigate the issues and what it would take to fix. Our hope is to stack rank what’s easiest and most valuable to fix and then attack the list aggressively.
• What’s needed to proceed: We need air cover from executive leadership for probably about a month while we get this fixed. Meaning, we need to pause our current product work and not have to answer questions about why. This is important work, leverageable by the entire organization.

What we learned is really the key deliverable, and something potentially interesting to many people across the company. Cost to learn is a chance to optimize for and highlight efficiency, as spending a year of engineering time carries much greater opportunity costs than running some efficient, qualitative testing. Plan to proceed lets people know the outcome of the learning and how it affects the way forward. And finally, what’s needed to proceed spells out what a manager, executive, or anyone outside the core team can do to help.

This is a rough sketch and could use plenty of iteration and refinement, but one thing I like about it is that while there are plenty of legitimate and illegitimate excuses for not shipping, there is really no excuse for not learning. In other words, a team could spend an entire quarter (or much longer) shipping absolutely nothing, even though they are doing all the right things. However, if a team is not learning quickly and regularly, they are almost certainly doing something wrong.

I also like that a re-orientation around learning gets people thinking in an entirely different way.

“What’s the minimum we can ship with?” becomes “How might we learn X most quickly?”

“What do we want to release next quarter?” becomes “What is most important for us to learn about our product next quarter?”

“How can we ship more often?” becomes “How can we increase the pace of our own learning?”

None of this means you won’t also have to ask questions about shipping, but shipping simply becomes another way to learn… alongside research, prototyping, and many other methods. It’s still what you ultimately want to get to, but it’s more a by-product of the methodical learning you hold yourself and all teams within the company accountable for every week, month, or quarter.

Some of today’s companies who learn and evolve the quickest have surely already operationalized some of this sort of thinking, even if informally or by accident. If you’re reading this and you’re thinking to yourself “we already do all of that!”, then that is fantastic (and I would love to hear more about your process in the comments)! If, however, this sort of re-orientation sounds refreshing to you, start talking about it with your team and see what steps you can take to try it out on a project or two. I’m curious to hear what works best for everyone.

(This post also available on Medium.)

Say hello to Mike Industries, Version 3.

What is wrong with the old Version 2, you ask? Well:

• It’s not responsive.
• It ingests and displays all of my Tweets and saved Tumblr links, which seems like overkill now.
• Because of all the peripheral stuff being displayed, WordPress isn’t able to assemble the page very quickly and browsers are also slow to render it.
• It doesn’t take advantage of any of the great HTML, CSS, and related advancements that have developed in the last few years.
• It was just time for a change, and I felt like getting back into pixels and code again.

While I’ve spent the last few months putting this together, it only occupied a day or two of time per week. Lots of fits and starts, including periods of frustration and reflection where I’ve asked myself “Why am I not just moving everything to Medium?”

The answer to the Medium question is two-fold, for me:

1. As someone who designs things for a living, there is a certain amount of professional pride in creating one’s own presence on the internet. It’s kind of like if an architect didn’t design their own house. Almost every non-architect — which is 99% of the world — should live in a house designed by someone who knows what they are doing, but if you have the skills, why not use them?
2. In working through all of the various issues that come with designing a modern, responsive site, I gained a whole new appreciation for how well-built Medium really is. I mean, I knew it was well-built before, but it really is the highest-quality solution for most people out there. Aside from the exquisite craftsmanship, the network effects that now occur around well-written articles on Medium rival and sometimes exceed those experienced during the Blogging Days of Yore. For this reason, I going to — at least initially — cross-post articles on both Mike Industries and medium.mikeindustries.com, which is a sub-domain on the Medium platform. Coincidentally, I have also owned meatium.com for a long time, so if I ever start up a food blog for carnivores, I might host Meatium on Medium.

This site, when active, has always been a bubbling cauldron of experimental hacks and concepts, and I’m happy to say that version 3.0 continues this tradition. The site is still a work-in-progress, but below is the philosophy behind it, as well as a host of implementation tidbits.

First Principles

In the past, I’ve taken a certain amount of pride in some of the bells and whistles around this site. The landmark feature of Mikeindustries 1 was a header displaying a background image of the view outside my apartment window, updated every few minutes. The site also had a font selector in the sidebar which allowed you to customize the typeface throughout the site. Back in 2003, that was kind of cool… to me at least. Mikeindustries 2 was all about sIFR and separate columns for articles, links, and Tweets.

I started off Mikeindustries 3 with the opposite approach: what is the bare minimum I need? When an article is displayed, do I need any elements at all besides the text itself? If I get draconian here, can I do the whole thing as one template to rule them all? If I put everything someone might want to know about me into a single About page, do I even need persistent navigation?

And perhaps the most confounding question of all: what about my design work? While part of me really wants to keep it all online and easily accessible, the other part of me recognizes how dated all digital work gets and wonders if it’s worth it at all. The most recent version of my portfolio is also in Flash, so clearly a straight porting wasn’t going to happen.

In the end, I decided to take a down-to-the-studs approach, launch the foundation on May 1st, and then slowly add things back in if and when necessary. At this point in my career, design leadership is a bigger part of my skillset than hands-on design, so I imagine any sort of portfolio I might put together in the future would serve a different purpose than it did 7 years ago.

Content

I settled on three types of content for the new site: What I’m Writing, What I’m Reading, About Me. The first is made up of original blog posts authored in WordPress. The second is a running list of articles I’ve faved in Instapaper. While I read of lot of things on the internet and Tweet out links to many of them, I’ve found that my Instapaper faves represent all of the best long-form stuff I’ve come across, and that is really all I want to publish here. So… the main Mike Industries stream is now comprised of What I’m Writing and What I’m Reading. If you want to dig into either separately, there’s navigation for that. The third type of content is a simple About Me page for people who are interested in contacting me or finding me on other networks.

WordPress

Hoooooooboyyyy. Where to start on WordPress. I love WordPress, I am so glad it exists, and I’m happy to host my stuff on it, BUT, it is an absolute bear for someone with my particular skills inventory. If you have no skills at all, you just pick a theme, do all of your customizations in the GUI, and be happy with what you get for free. If you are a PHP wizard who has worked on dozens of custom WordPress installations, you just build everything from scratch, hack when you need to hack, and know where all the bodies are buried. For someone like me, however, who knows HTML and CSS very well but is only a script kiddie with PHP and WordPress functions, the task of building any sort of site is daunting.

Here’s generally how my progression went:

Step 0: Spend a week or two in Sketch coming up with a great design that fits my objectives and makes me happy. No problem.

Step 1: Begin coding from scratch. The HTML and CSS part go well, but when I get to the task of snapping it into WordPress templates, I realize there is so much WordPress functionality that already exists that I am not getting for free if I don’t use a existing WordPress theme.

Step 2: Begin looking for an existing theme that remotely resembles my design. Realize there is none. I probably wasted an entire week on this.

Step 3: Take the one that seems closest anyway and then crack it open to see how it’s coded. HOLY SHIT FUCK THAT THERE IS NO WAY I AM USING THIS RAT’S NEST SPUN FROM GARBAGE.

Step 4: Look for another theme that is as simple as possible and just gets me to a reasonable baseline. I wasted another week or two on this as every theme I looked at still included things I didn’t need or want. Maybe I am misjudging, but even the standard “twentyfifteen” theme that comes with WordPress seemed like overkill.

That’s when I realized why I was having such a hard go at it: most themes are built for non-technical people so they can make customizations in the WordPress GUI, and thus, contain a ton of extra code to make this possible. While that is noble, it’s not for me.

This is one of the many points when I almost threw my hands up and just moved to Medium.

The last thing I tried ended up being the right approach for me: take the simplest built-in theme (which I believed was probably twentyfifteen), keep all of the template files, but strip them down to nothing except a few bare-bones functions that I know I needed.

Using an almost blank set of templates, I was able to get Mike Industries 3 90% working within a week or two. But, as the saying goes “the first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

That last 90% would be spent on some nasty CSS layout bugs but also some really cool stuff, outlined below.

Elasticity

No one would build a website these days without crafting it to adjust nicely across a wide range of screen sizes. Down in the coal mines, we call this Responsive Design, as most people reading this blog already know. I’m calling this section Elasticity though, because the solution I settled on feels more elastic than anything else. The last time I redesigned this site, there was no such thing as “vh” and “vw” units. Now there are, and they are amazing! Most type blocks, as well as some div heights and widths are now specified as a percentage of the viewport width (vw) or viewport height (vh). For instance, on desktop, you’ll notice that the large image goes about 70% down the screen, allowing for a preview of the first article. Also, if you stretch your browser window horizontally, you’ll notice that the type resizes with it. There are also upper and lower limits for type so things don’t get too cray-cray. I’m really digging this method of sizing. As for the traditional concept of responsiveness, I only used one breakpoint; you either get the one-column mobile/tablet layout or the two column desktop layout. Seems more than adequate, especially considering I’m also doing some other things like limiting paragraph line-length, which maximize readability at certain screen sizes.

Typography

As I mentioned, type sizing is dynamic, which is cool, and I decided to stick to a system face, Avenir on Apple devices, Roboto on Android devices, and Helvetica/sans on everything else. This is an area where I may switch to a webfont eventually, but I really hate it when sites go blank for a few seconds as they load their fonts. Even with sIFR, we never recommended people use it for large bodies of text. I find Avenir looks pretty sharp here actually.

As has been my practice in the past, I don’t use grids — baseline or otherwise. Grids are sort of like the equivalent of weighing your ingredients when you bake. They are the “correct” thing to do and they ensure a certain level of precision, but they aren’t always necessary, depending on your experience and your goals. Furthermore, unlike in baking, if you got an element wrong, you can fine-tune it at any time. (I should also note here that I’ve been doing a lot of baking lately and I absolutely weigh my ingredients, for now.)

Imagery and color

Imagery and color are where things got really fun in this project. I initially built a lot more than what I’m launching but then ended up commenting a lot of it out for now, because I’m not sure I need or want a user navigable gallery of photos as part of the core experience. Not until I think it through a little more, at least.

My primary goal for imagery on Mike Industries 3 was to build a system which allowed me to keep things fresh with minimal effort. In thinking what the dead-simplest flow would be for featuring new images, I actually settled on email! If I could just email any photo on any device at any time to a secret email address and that would publish it to the site, that would be fantastic. Luckily, there is a WordPress plug-in called Postie which facilitates this sort of thing. I tried to stay away from plug-ins entirely, but this one only hits the publishing side and not the rendering side, so it seemed like a great choice. The next step was figuring out how to integrate it such that its output could be used as a randomized series of background images in the header. I’m not completely settled on this format yet, but I essentially have it listen for new images sent to an email address and then publish each as a post with a special tag. Then, in PHP on the rendering side, I have WP loop through these posts, create an array of image URLs, titles, and dates (from EXIF data), and then display one randomly when you hit the front page and a few other pages. If an individual post has a “featured image” attached to it, I use that image instead. I’d post the PHP, but that would expose me for the hack that I am. Pay no attention to the code behind the curtain!

Alright, so, big beautiful images all over the site with minimal effort to keep fresh! What could go wrong? Well, the downside is that big beautiful images are also big in load time. For people with giant retina monitors and good connections, I love serving up a crystal clear phatty, but for more constrained environments — especially mobile — that 800k file would be much better off at 50k or so.

There are SO many ways of dealing with adaptive image sizes these days, but most of them left me unimpressed. Even srcset, which is an emerging standard, feels wrong to me. I’ve never liked the idea of hardcoding image sizes in HTML and srcset makes this even worse. To me, the ideal long-term solution has the client send some screen resolution info to the server and the server dynamically decides what image to send. Luckily for me, someone already wrote something like this a few years ago: Matt Wilcox‘s Adaptive Images. For some reason, it’s gone largely unsupported and dormant since then, but I found it to work perfectly for my purposes. The mechanism is simple:

1. All requests for images get intercepted by PHP.
2. PHP reads a cookie with the user’s viewport resolution information.
3. PHP then checks to see of a version of that image at the appropriate resolution breakpoint has already been cached. If so, it serves it.
4. If there is no cached file at the right resolution yet, or if the cached file is stale, PHP creates one and then serves it.

Super simple and works with very little configuration or retrofitting of existing imagery. This was important to me as I’m not about to sign up for going through 10 years of HTML IMG code and changing a bunch of shit.

Alright, so now that all of our images are adaptive in file size and resolution, we’re done, right? Turns out, not exactly. Even on fast connections, there is still an annoying lag before a large image loads and renders. Because the rest of the layout renders instantly, I had a giant placeholder space to figure out what to do with. Once again there are SO many ideas for what to do in this situation. You can read a good run-down of a bunch of them here. Not surprisingly, Medium’s is probably the best implementation. Since I’m trying to keep things as simple as possible and not use javascript except where absolutely necessary, I came up with my own serviceable solution.

Using the aforementioned Adaptive Images PHP script as a baseline, I added a couple of lines to it that save out a tiny, 10-pixel wide version of every image as well as the chosen adaptive size. Then, I load that tiny image as a background-image of a div behind the main photo div and stretch it to fit the entire dimensions of the div. The effect looks amazing in Chrome and slightly less good in Safari, due to surprising differences in how they interpolate images. As a result, the tiny sub-1k file loads instantly, showing you an interesting gradient mesh that approximates the full image, and then the full-image quickly fades in when it is loaded (accomplished with the css transition property).

For the icing on the cake, I wanted to set the color scheme of the page (type, sidebar color, etc) to match the dominant color in the photo. The first time I saw this done, it was in Dave Shea’s last Mezzoblue redesign a lonnnnnnnng time ago, but the color was set manually. I’m too lazy for that, so I began looking for ways to find dominant colors programmatically. A lot of people have tried different methods to do this and most of them don’t work very well. The one I found that worked the best and was easiest to implement is called Color Thief. Unfortunately it’s javascript-based, but in this case, I’m cool with that, because if I was going to do it server-side, I would want to build something that only did the calculation once and stored it. In fact, let me just call timeout and describe how this entire set of things should work in WordPress, in case someone knows how to build it:

1. Photo is uploaded into WordPress.
2. WordPress stores tiny-resolution file for the gradient mesh version.
3. WordPress performs dominant-color and perhaps even dominant-palette calculation a la Color Thief and stores it as attachment metadata.
4. All of this is just magically available in PHP.

So, since none of that exists yet — to my knowledge, at least — I’m just using ColorThief.js for now, which is why you see the color palette fade into prominence in concert with the high resolution imagery. I’m looking forward to streamlining this when someone builds something like what is described above. Is that you? I think that should be you!

Final Retrofits

Throughout this entire redesign, I was worried about how all of my legacy articles would look. Clearly there are going to be some weirdly formatted older posts that contain some experimental stuff, but what about the 99% of posts that use a pretty standard mix of (non-responsive) text and inline imagery? Turns out, one style rule pretty much fixed everything: img {max-width: 100%; height: auto}. That one rule kept all my images from sliding off into the gutter on smaller screens and made the site look like it’s been responsive for years. Magic.

One Last Thing: Blog Comments!

I got most of the way through this redesign thinking I would just keep comments turned off and hide all of the tens of thousands of great comments that readers have written over the last couple of decades… because who does blog comments anymore??? But then I got to thinking, I miss comments, and I never really had much of a comment spam or trolling problem on here before… so COMMENTS ARE BACK BABY. What’s old is new again. YOLO.

… and with that, I’m happy to ring in Mike Industries Version 3. It’s great to be back.

I think that there’s a lot of institutional knowledge in our field, especially about what makes for a productive engineer. But while there are a good deal of books in the management field about “expert” roles and responsibilities of non-technical individual contributors, I don’t see too many modern books or posts that might shed light directly on what makes for a good senior engineer.

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.