kai_mactane | Entries tagged with bad ideas

And by “long live the PROTECT IP Act”, I really mean, “let’s kill the PROTECT IP Act, as quickly and as dead as possible”.

[Update: At least one petition to the US Congress opposing this bill can be found at Demand Progress; I will update with others as I find out about them.]

Back when COICA was winding its way through legislative committees, Representative Zoe Lofgren (D-CA) gave an interview to Ars Technica, in which she said:

I was in the Congress when we did the Digital Millennium Copyright Act. [The content industry] wanted to go farther; at one point, the original draft outlawed Web browsing, which I thought was interesting. We did the bill, and they’re complaining. It’s what they wanted, but it’s not enough. Now they want to do something else, which is really pretty draconian

Rep. Lofgren also predicted that “if this passes, in a couple years they’ll come back with something even more draconian.” She was mostly right: Even though COICA was killed before reaching a floor vote by Senator Ron Wyden (D-OR), they’re back with something more draconian anyway.

As Wired notes, PROTECT IP, like COICA, would force credit card companies, ad networks, and DNS server to enact the appropriate form of shunning or blackholing against sites deemed “infringing”. Credit card companies could no longer process payments for the site; ad networks could no longer serve ads to them, and DNS providers would have to cease resolving their IP addresses. But PROTECT IP goes further, requiring search engines to censor their own listings.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

Back when I got my Palm Prē, I noticed that it wanted to store various of my information on Google’s servers. I thought I’d kept it from doing so; I sure wasn’t using Gmail on a regular basis. I configured the Prē’s email client to check my own account on mactane.org, and I thought everything was fine.

Eventually, I gave up on the Prē and switched to my current, Android-powered Samsung Epic. I figured I was in for a boring day of transferring my contacts over manually… until I discovered that many of them had been synced to my Gmail account, and so they showed up in my new phone without me having to do anything.

Considering all the work I had to go to in order to get my to-do list items, memos and notes transferred over manually… I decided that having stuff transfer automatically was actually pretty damn cool. Since I got my Epic, I’ve been picking “Save contact to Google” whenever I create a new contact. So, if I accidentally drop my phone on the street and it gets run over by an 18-wheeler and then the fragments get kicked into the bay and sink to the bottom, I can just buy a new Android phone and have all my contacts “magically” appear there.

On the other hand, all my contacts are sitting on Google’s servers.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

When a company says “we can’t afford a QA department”, what they’re really saying is, “we accept that our software will be infested with bugs, and quality is not important to us.” When they compound this basic error by saying, “the developers will just have to do their own QA”, they prove that they have no respect for developers or QA people, and you shouldn’t work for such a company in either capacity.

(Of course, a company like that isn’t about to hire any QA testers, so you folks haven’t got the option of working for them. And I’m not a QA tester, I’m a developer. So the rest of my advice is pretty much aimed at fellow devs — but that doesn’t mean I don’t respect you QA folks. Seriously, y’all deserve a lot more respect than you get, and I love it when you make my life easier by finding my bugs for me.)

The skills, talents, and basic mindset that make a good developer are entirely different from the ones that make a good QA person. Asking one to do the other’s job is a mistake as fundamental as expecting graphic designers and accountants to swap places. Let me explain:

Developers hate repetition. We hate having to repeat anything more than once or twice; that’s why some of us become developers in the first place: because we can write programs that automate repetitive drudgery, and hence banish it from our lives.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

Once upon a time, Netscape invented the <blink> tag. And people saw the <blink> tag, and put it on their web pages, and thought it was good. And the rest of us saw the <blink> tags on those pages, and screamed, “No, you morons, it is bad! It distracteth the user mightily, for lo, our eyes are built to take especial note of motion and changes in light, for they might signal the approach of predators.”

And so, in the fullness of time, most people learned to never, ever use the <blink> tag. And that was good, for a while. But more recently, people have started putting new — and even worse — moving doo-dads on their sites: Animated Twitter feeds.

I’m talking about the kind of feeds that refresh or scroll every five seconds (or sometimes more frequently). You can see them all across the web. Here are just a few examples:

Any comments page on Whedonesque (Joss Whedon’s site). Try to read the text, and your gaze gets pulled over to the constantly-updating “Twitteresque” box on the right.
Any article on WikiHow. You have to scroll down one screen before the “Recent Changes” box becomes visible on the right — but that just means the problem isn’t apparent to a cursory, design-level glance; it only becomes obvious when you try to actually use the site for its intended purpose, by reading the content that’s published on it.
Even Webmonkey has gotten in on the action. Again, you need to scroll down a screen (unless your browser is way taller than mine), but the “Recent Articles” box will try to grab your attention as soon as you read past the screenshot in the main article text.
Like Webmonkey, you’d think TechCrunch would know better than to do this. Admittedly, they do put their “PostUp Beta World’s Best Tweeters” box further down the page, but their articles are longer, too.

Why would someone put something on their web page that effectively says, “Hey, don’t waste your time reading my content! Go look at my Twitter feed instead! Or even at some total stranger’s Twitter feed!” I’m honestly mystified. (That’s why my own Twitter-feed widget, Hummingbird, does not and never will have any kind of auto-scroll feature.)

But what mystifies me even more is: Why would people who (I presume) would sneer in disgust at the very idea of putting a <blink> tag on one of their pages — even for just one or two words — then turn around and put a much larger, more annoying motion distraction on every page in their site?

The fact that it uses AJAX and a Web 2.0, RESTful API doesn’t make a paragraph-sized chunk of never-ending motion any less of a design and usability nightmare. And this is not exactly a new concept: the W3C advised against constant motion back in 1999.

At that, they were Johnny-come-latelies compared to Jakob Nielsen, who called out “constantly running animations” as far back as 1996. In other words: The days of Netscape Navigator version 2.0x called. They have some usability advice for you… that you apparently still haven’t learned yet.

It can’t be that hard to figure out… can it?

Originally published at Coyote Tracks. You can comment here or there.

First, a note about pingbacks: Pingbacks simply let you know when another LJ user posts an entry (on LJ) that links to one of yours. It does this by adding a screened comment to your entry, which also means you get your usual comment notification. If you take no action, nobody else sees a thing. (You could unscreen the comment, if you want.)

I have no problem with this.

Then there's that Facebook crosspost feature. That's a little more dodgy. Just to make clear what it does and doesn't do (based on Livejournal's FAQ entry called "How do I update my Facebook or Twitter when I post to LiveJournal?"):

If you set it to crosspost your own entries by default (or automatically), it will do just that — but only for public entries. As I understand it, it will not send your friends-locked posts to other services.
If you set it to crosspost your comments by default (or automatically), it will crosspost every comment you write... even if that comment is on someone else's journal. Even if that comment is on someone else's friends-locked post.

Note that I'm taking Livejournal's word on this, perforce, because I deleted my Facebook account a few months ago. (Yes, because of privacy concerns. Funny, that.)

A public comment on the announcement about this sums up the problem pretty well: “Say, for example, you complain about your manager at work under f-lock. Someone can then reply with, "Man, your manager sounds like a bitch", and crosspost that to their Facebook. The possibility for badness is epic.” (I see no problem in linking to or quoting a public post. The main substance of the objections to this is that it tends to publicize information that was intended to be friends-locked.)

Some people have pointed out that a person who can see one of your protected entries can always copy-paste the whole thing. True enough, and that's not even really a technological problem; it's a social problem. If you tell a friend a secret verbally, they can always violate your confidence and spread the "secret" far and wide. No technology can guard against people deliberately breaking trust with you.

However, this setting would automatically and habitually publish one's comments to Facebook, without the person having to take any deliberate action. This makes it very easy to forget about. And totally aside from the way people can leak information by posting things that make it obvious what they're responding to, there are also the people who sometimes quote part of the post they're responding to.

In general, this is a good thing. Heck, I do it myself whenever I feel it's warranted. But until now, we've all done so with the knowledge and understanding that what we copied and quoted was staying on the same page, with the same read permissions.

That's no longer true. Now, if Joe or Jane responds to someone's friends-locked post, their comment can be automatically crossposted to Facebook without my even thinking about it, based on a checkbox they ticked at some point in the past.

Or, more apropos to my life: If I write a locked post, and my friend Stan writes a response that quotes some of my text (because it's the sensible thing to do in that context), Stan can accidentally export my words out to a service that I've deliberately severed all ties with. Even if he'd never consciously, deliberately do so.

That's what bugs so many people about this. That what bugs me about it, too.

My policy has always been that if I post something publicly, with no friends-lock, that means it's intended to be public. Link to it freely, no permission needed. I see no reason to change that policy, and you'll note that I've made this post public.

But to my friends who comment on my journal: Please, don't crosspost my locked stuff to other services. And don't crosspost text that makes it obvious what I must have written, either. I locked it for a reason.

Current Mood: thoughtful

It’s awfully convenient for Google that their famed corporate motto, “Don’t be evil”, doesn’t actually specify or define what counts as “evil”. And without any definition, they’re pretty much free to do anything they want, and just declare it not-evil.

Now, some of the things they’ve done have just been misguided. For example, I really, honestly believe that when they sniffed people’s unencrypted wifi traffic while doing Street View mapping drives, they weren’t being purposefully malicious, just absent-mindedly misguided. (I also have trouble getting too upset about sniffing unencrypted wifi signals — yeah, it’s kind of bad, but if the people who owned those networks really wanted privacy, would it have been that hard to turn on WPA?)

And then there was the bit where they auto-subscribed everyone with a Gmail account to Google Buzz — which, by default, made huge amounts of information public that shouldn’t have been. This was a really massive mistake, but given the way Google backpedaled from it, I still believe that they were just misguided and didn’t think things through at all, rather than actively wanting to cause harm.

But when Google Checkout tried to impose a “no adult content” rule on Dreamwidth? That’s a lot greyer. In essence, what Google did was tell an organization devoted to enabling free speech that it had to muzzle its users.

Google has the right to choose who it wants to do business with, based on whatever criteria it wants. But just because their choice is legal doesn’t make it “non-evil”. It’s not clear just exactly what “adult content” would have included, but there’s a strong likelihood that it would have included things like:

safer-sex information, including family planning, contraception, and how to use condoms properly;
discussion of rape, including rape survivor groups;
promotion of equal rights for sexual minorities

Keeping information like that off the Internet? Is not helping the world. Suppressing that kind of information harms the world, and I’d qualify it as a straight-up evil act.

It’s possible, though, that they only mean “actual pornography” (however you define that). As much as I personally may like both pornography itself, and the right to disseminate and receive it, I have to admit that simply choosing not to do business with a company that helps people publish it is not, in itself, evil.

So what about entering into secret back-room agreements to try to do an end-run around Net Neutrality and everything it stands for? And then promulgating a legislative framework proposal for Internet governance that would turn the principle of Net Neutrality into a defanged, loophole-ridden and corporation-appeasing shadow of its former self — while pretending, on the surface, to support it?

In effect, this means a full-scale attack on the core of a free Internet. This is something that reminds me of when Microsoft was going to try to “de-commoditize [the] protocols” that formed the basis for the Internet and World Wide Web, back in the first Halloween memo.

If there is a way in which this isn’t evil, can someone please explain it to me? Because it sure looks evil to me.

In the meantime, there’s one tiny problem with trying to boycott Google: They make some damned useful products. Still, if you want to start reducing your reliance on Google, here are some pointers that may help.

Originally published at Coyote Tracks. You can comment here or there.

In my ongoing job search, I’m sometimes asked by recruiters: “How many years of experience do you have with [name of some technology or skill]?” It’s a somewhat reasonable question when the item involved is a programming language or technique that I use every day, or at least every week. But there are far too many things that it just doesn’t work for.

For example, I can reasonably well say that I have 5 years of experience with AJAX: I taught myself AJAX in the summer of 2005, and have been using it pretty consistently since then. But how many “years of experience” do I have with SQL?

I started using it around 2002 or 2003, but if I say that I “have 7 years of experience” with it, I give the impression that I’m some kind of SQL expert… which is definitely not true. It’s the sort of thing I use about once every week or two. I’ll set up a database schema, maybe even type out some raw commands in a MySQL command-line client, and then I’ll just let whatever framework I’m using handle all the details for me.

So, what sort of answer should I give to the question? The sense in which I “use” (or “have experience with”) SQL is simply not the same as the sense in which I use things like JavaScript, PHP, or CSS. (The sense in which a DBA uses SQL is probably comparable to the sense in which I use CSS… but I can’t be sure, not being one myself.)

At least the idea of having “a year of experience with” SQL does make a certain sort of sense. What should I say when asked how many “years of experience” I have with XML or JSON? These aren’t really “technologies” so much as data formats. It’s like asking someone how many years of experience they have saving files in .txt or .doc format (as opposed to using Notepad or MS Word).

The only metrics that are worse than “years of experience” are: “When did you start using Technology X?” (which, thankfully, very few people have asked), and the utterly subjective “How would you rate yourself with Technology X, on a scale of 1 to 10?” (I need to write an entire post about that particular metric, when I get a chance.)

Originally published at Coyote Tracks. You can comment here or there.

Just under a month ago, an iPhone developer from Australia — one who’s previously defended Apple’s approval process — had his own app suddenly dis-approved by Apple. According to his blog post about the sudden revocation of approval, “I had convinced my company to take a gamble and make some apps for Apple’s Store. Tennis Stats had been a great success and we wanted to get on the iPad train with My Frame. Things were going well, new features were being planned money, real money was being invested. Then Apple pulled the pin”.

I could say all sorts of things about schadenfreude, or how the developer — who goes by the nom de plume “Shifty Jelly” — should have seen this coming. But the guy’s already having a bad enough month, and there are broader issues to examine. Among them the thought raised by commenter Erik K. Veland:

Remember when Apple cracked down on Podcast downloaders? It was because they themselves were introducing this very feature in iTunes.

[I] would surmise [that] Apple is now bringing “widgets” to their dashboard in the near future, and that they are pre-empting any apps conflicting with the “duplicate functionality” clause. [historical links, added by Kai]

Once you’ve considered Apple’s penchant for banning apps that compete with features that are built in to the OS, you’ve got to consider how this compares against other companies’ competitive practices.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

One of the biggest problems with Flash isn’t Flash itself. It’s Flash designers. More particularly, it’s Flash designers’ basic failure to understand why certain UI elements are the way they are. This leads to one of the most common Flash designer diseases: The drive to reinvent basic UI elements. Poorly.

Page Transitions

When a user clicks a link, they’re sending a specific message with a specific intent. That intent is “show me the information I’m interested in”. It’s not “show me a nifty animation effect that takes another 5 seconds out of my busy schedule”.

Users (rightly) consider page transitions to be the space in between what they’re actually interested in. Don’t force them to pay even more attention to them.

Reinventing Scroll Bars

This error is so common, and people screw it up so badly, that I’ve already written an entire post about it. However, I’d be remiss in not listing it here, as well.

Auto-Playing Sound

Speaking of things I’ve written about before… people have been complaining about auto-playing sound since Netscape Navigator first gave us the ability to include such an abomination, way back around 1994. Eleven years later, I listed auto-playing music as a “no-brainer”, in the sense that excluding it from your site should be a no-brainer decision.

Some people will apparently never learn.

Assuming Everyone Has Enormous Bandwidth

Yes, broadband is much more common in the United States now than it used to be. That means that people are less ready to wait a long time for your page to load, not more. And a designer, developer, or other professional who understands how HTML, CSS, and JavaScript work can arrange things so that at least part of the page (or AJAXified web app, or whatever) is usable when only part of the code has arrived at the user’s browser.

If it’s possible to provide the user with something more useful than a “Loading…” indicator before all the code has arrived, then why do Flash developers never actually do so? (This is a real, not rhetorical, questions, and an open invitation for Flash designers and developers to answer it.)

Here’s Why So Many People Disparage Flash “Designers”

For a trifecta of awfulness, check out the site for Alembic, a bar in San Francisco. On my fiber-optic, 6 Mbit connection, it takes nearly 10 seconds just for the site’s intro to load. Then, once the little rocks glass is full of liquor, the page blasts some sound at me — sound that doesn’t even convey any information. (Believe it or not, I already know what a crowded bar sounds like.)

Then there are the slow transitions from sub-page to sub-page. All told, it took me a ridiculous amount of time just to find out what their hours were. But for a true dose of awfulness, try clicking on “Menus”. Then try clicking on one of the other main menu items. The site’s “background” doesn’t even realize that there’s still a “window” open in front of it… even though both the “background” and the “popup” are just visual elements of the same Flash object!

The real kicker comes when you try clicking on one of the menu pages. Rolling over zooms them a bit, but clicking? Launches a PDF document! A separate one for each page! That zoom effect was apparently just a red herring, and trying to get the place’s full menu would require seven separate PDF downloads.

I suppose they could, somehow, have disrespected their users a little more. At least the page doesn’t literally throw a drink in the user’s face. Just figuratively.

Please, if you’re designing your sites in Flash, don’t make them like this. Don’t be the web equivalent of “that guy”.

Originally published at Coyote Tracks. You can comment here or there.

First things first: Never actually do this. This is just a fun curiosity, for amusement value only.

Because of the way JavaScript’s search() method works, you can do:

var my_url = 'http://kai.mactane.org';
if (! my_url.search(/http:\/\/kai.mactane.org/)) {
alert("Your URL is http://kai.mactane.org");
} else {
alert("Nope, your URL isn't http://kai.mactane.org");
}

Try running this, and it will correctly claim that “Your URL is http://kai.mactane.org” — even though there’s a ! at the beginning of the test. What gives?

That exclamation point looks like it’s saying: “If the search for http://kai.mactane.org within the given string fails…” But what that test is really saying is: “If the search for http://kai.mactane.org returns Boolean false — or anything that evaluates as Boolean false…”

What that search() call actually returns is the character index at which the needle is found, or -1 if it isn’t found. Since the needle is found at the very beginning of the haystack — at character index 0 — search() returns zero. Which evaluates to false in a Boolean context.

If the needle isn’t found, the search will return -1 — which evaluates as true in a Boolean context!

Effectively, the ! operator is reconciling the disagreement between search()’s idea of falsehood and if()’s idea of falsehood: search() returns -1 for a false result (a failed match), but if() considers -1 to be true, not false.

This trick only works with needles that you are sure will only occur at the beginning of the haystack.

Once again, you should never, ever actually write code like this for any serious purpose or in anything you intend to deploy in the real world. The maintainability problems are not worth the amusement of confusing all your co-workers with a test that looks reversed. Instead, use a positional anchor in your regex, and explicitly test against -1…

if (my_url.search(/^http:\/\/kai.mactane.org) != -1)

…like any sensible JavaScript coder. (Yes, that last bit is intended to be ironic. I wrote something once about the silliness of having to add that extra test; I’ll have to see if I can find it and republish it here. )

Originally published at Coyote Tracks. You can comment here or there.

If you’re going to reinvent the wheel, you should at least make sure your new version is somehow better than the previous kind. Reimplementing standard UI and OS widgets is one of the most common ways developers reinvent the wheel these days — it started with Flash developers building their own controls, and has now spread to Adobe AIR and Silverlight.

It might be a welcome trend, if the replacement widgets people were building had more functionality than the OS-native ones that are available for free in any other context. But usually, the widgets I see in these frameworks have less than half the functionality of the things they try to replace. I’m going to pick on scroll bars for now, because I’ve seen them horribly mangled too many times.

To start with one aspect of scroll bars that we often take for granted: Can you guess which of these text boxes contains more text?

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Quisque est est, luctus quis suscipit et, lacinia ac odio.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

The following is a copy of what I just posted on the Palm Prē forums:

I woke up this morning to find that the webOS 1.2 upgrade had been pushed to my Prē automatically. I was happy, until the reboot finished and I saw:

Signed Out

You are no longer signed in to your Palm Profile on this phone.

If you plan to use this phone again, you can leave the files on your USB drive intact.

If you’re done using this phone, you can erase all your data on the phone and return to its factory default.

[Just Restart]
[Erase All Data]

The [things in brackets] represent buttons.

Read the rest of this entry »
Originally published at Coyote Tracks. You can comment here or there.

So, Palm was recently caught spying on its users. Major kudos, by the way, to Joey Hess, who initially broke this story. For those who haven’t kept up, various other news outlets and blogs have also been reporting on it.

Palm’s response to this problem is a single paragraph of corporate PR-speak:

Palm takes privacy very seriously, and offers users ways to turn data collecting services on and off. Our privacy policy is like many policies in the industry and includes very detailed language about potential scenarios in which we might use a customer’s information, all toward a goal of offering a great user experience. For instance, when location based services are used, we collect their information to give them relevant local results in Google Maps. We appreciate the trust that users give us with their information, and have no intention to violate that trust.

The problems with this statement are:

There is no indication of how to turn off this particular piece of data collection. Not on Palm’s web site, not in the user manual that came with the Prē, and not in the Prē’s user interface.
For all the “detailed language” in Palm’s privacy policy, there is no slightest indication — anywhere — that they collect information about what applications the user runs.

It’s particularly interesting to look at the “On-Device Services” part of the privacy policy: It mentions types of data that will be collected “If you use services we provide” (emphasis added). For example, they say, “When you use a remote diagnostics or software update service, we will collect information related to your device (including serial number, diagnostic information, crash logs, or application configurations)”. This is the only mention of collection data about a user’s applications, and it clearly starts with “when you use a diagnostic service”.

It doesn’t say “once per day, no matter what”.

Other items under “On-Device Services” start with “When you use a back-up and restore service…” and “When you use location based services”.

All of this suggests that users have some sort of control over what gets sent and when. The Palm Prē’s “Location Services” preferences item has a control labeled “Background Data Collection”, with the caption: “Allows Google to automatically collect anonymous location data to improve the quality of location services.” (This is after other controls labeled “Auto Locate”, “Use GPS”, as shown at right. If you turn on Auto Locate, you also get a control labeled “Geotag Photos”.)

It doesn’t say that Google (or anyone else) will collect data on what apps a user is running. And it strongly implies that this data will only be collected when I actually run an app that uses location services — for example, Google Maps, or OpenTable (which wants to know where I am so it can try to find nearby restaurants).

And it blatantly claims that if I turn off that switch, it won’t send my data off to big corporations any more.

So far, I’ve verified a few things:

The application data log includes installs, uninstalls, and launch and close times for all apps, not just Palm’s official ones. Homebrew and third-party apps are included.
Flipping the Background Data Collection switch does not turn off the contextupload process that’s responsible for sending the information to Palm’s servers.
Nor does it stop logging application launch and close times. I’ll repeat that: My Prē is still logging application launch and close times into /var/context/contextfile, even though I have Background Data Collection turned off.

We in the technology business have a technical term for what Palm is doing when it claims that it “offers users ways to turn data collecting services on and off” in the context of this particular data. That term is: lying. Palm is lying to us, pure and simple.

Originally published at Coyote Tracks. You can comment here or there.

In his latest entry on Coding Horror, “Windows 7: The Best Vista Service Pack Ever”, Jeff Atwood says:

I want the world to get the hell off Windows XP. A world where people regularly use 9 year old operating systems is not a healthy computing ecosystem.

I find this terribly, painfully wrong. The unintended consequence that comes from that mindset is: “Let’s make all the user’s hard-won experience and knowledge totally useless every few years.”

There are lots of reasons why I didn’t bother upgrading to Windows Vista (if you can call it an “upgrade”), but the one that’s relevant for this article is simple: I already know how to use Windows XP. I know how to use applications with menu bars. I don’t know how to use the Ribbon, and I don’t feel that I need to throw away my existing skills.

Maybe that means I’m not on the leading edge of the tech curve any more. Fine, so be it, but retraining habits and muscle-memory is an annoying, inconvenient task. There are times when the benefits are worth it.

Nobody has made a convincing case that Windows Vista’s blithe discarding of one of the four pillars of GUI design that’s been stable since the early ’80s — windows, icons, menus, and pointers — is one of those cases. In fact, the legions of people who bought computers with Vista pre-installed, and then paid more money just to use XP instead, argues pretty convincingly against such a move.

Mr. Atwood posits a world where people don’t use operating systems for more than, say 7 or 8 years. I’d like to counter with a world where the basic design of your car’s controls and interface changed every 7 years. Instead of a steering wheel, a pair of foot pedals, and a shift lever, suppose that the 2010 line of cars used a tiller lever and a single forward/back foot-slider. Or a joystick and throttle system, like a jet fighter.

Do you suppose the accident rate might spike?

I don’t know of any field besides computing where people think that it’s acceptable to completely redesign user interfaces every couple of years. In the terms of Kathy Sierra’s wonderful post, “Attenuation and the Suck Threshold”, redesigning your interface is a way of forcibly smacking all your users back down under the suck threshold. Instead of being able to continue to use your program, and gradually learn the new features, they have to drop everything they were planning on doing this week, and instead devote their time to re-learning how to use something they already learned before.

This is simply cruel. Please, don’t do it to your users.

There is a kind of fool who says, “This is old, and therefore good.” And another type of fool who says, “This is new, and therefore better!” But what kind of fool does it take to want everything to be new, or renewed, every few years?

Originally published at Coyote Tracks. You can comment here or there.