Archive for the ‘Classic Blunders’ Category

If I Followed Directions, I’d Still Be Looking

Tuesday, September 1st, 2015 by The Director

The instruction in the installation wizard is Press Execute.

There is, of course, no Execute button in the wizard. Nor, for the last four or five decades, is there one on the keyboard.

Lessons, of course, include:

  • Check to make sure your application’s text matches the interface, including instructions and error messages.
  • Test the installer.

The Users Don’t Always Want What Your Designers Want

Friday, July 5th, 2013 by The Director

Your designers probably want the latest cutting edge gizmos and paradigms in your applications. What do your users want? The familiar and the things they have already learned to use:

Ford Motor Co. is going back to buttons and knobs.

Punished by third-party quality reports because of the difficulty of using its touch-screen multimedia system, called MyFord Touch, the auto maker will reprise tuning and volume knobs for the radio as it redesigns existing models, a top Ford executive said.

It is a reversal for Ford, which has been a first-mover with installing mobile-phone-based technologies, voice recognition and touch screens in its vehicles. The systems have been a big selling point for Ford with its vehicles, but also have dragged down its reputation for quality.

. . . .

One of the things that bothered customers was the inability to quickly change the channel or volume on the radio through familiar knobs, he said. As Ford redesigns its vehicles, the flat control panels with add more buttons and knobs[SIC] and[SIC] the main screen will become simpler.

Users have other goals in mind with your software than building a portfolio to take to their next job interviews. In a lot of cases, they want to do the same things in the same ways they’ve always done things.

Granted, you do have to balance the same old way of doing things with any process improvement that your software brings, but far too often, design changes come from the minds of the designers and frustrate the users to no end.

Ever wonder why fast food restaurants and many less expensive department stores have very similar layouts to others in the chain? It’s because customers whose goals are getting a quick lunch or grabbing the essentials quickly, looking for the things they need (which includes the bathrooms and concerns as to whether they pay the server or a cash register by the door) mars the simplicity they crave.

Likewise, if your designers had their way, each freaking McDonalds would have a different layout, some with gerbil tubes between the floors so users could climb between the registers and the condiments stand. Because it would be different. Because it would satisfy their needs as architects.

Some stores and restaurants are destinations qua as eating experiences or shopping experiences. But your software rarely is. Nobody’s running your software to enjoy your software.

So make it easy for them to do what they do with your software, and don’t add weird or unknown design elements just to do that because your users might not appreciate it. Even on the ancillary functions, like changing the radio or clicking a button.

More Thoughts On Third Party Scripts

Friday, May 18th, 2012 by The Director

Joshua Bixby has an article about how third party scripts on your Web site can seriously hinder the Web site’s performance (Has your site’s third-party content gone rogue? Here’s how to regain control.)

In addition to the performance issues, you need to consider the following dangers and drawbacks of introducing third party code into your application or Web site:

  • You have no control over what they do.
    Sure, they tell you they do something, but that might not be all that they do. For example, a number of years back, I recall a Web site visit tracker that provided a “free” version and a paid version. A lot of people went with the “free” version, which not only provided rudimentary statistics on your Web site, but also served pop-under ads. By that time, most browsers allowed pop-up blocking, this was not always the case, and the host was making money on its users’ content. The provider of this free utility did mention it was going to do it in the terms of use, somewhere around the term that said you could not use the Web counter on Web sites discussing John Norman’s Gor books (no kidding). So not many people read it.
  • They can be an attack vector for malware.
    This is a corollary of the above point, but it’s worth noting in its own: Not even the third party vendors, especially ad delivery services, have control over what the code does. In many cases, that’s left to the person who buys the ad, and sometimes that’s a bad, bad man who wants to do bad, bad things to user computers and inserts attack code into ads that the third party code serves up. As a matter of fact, the last attack I know of on my client machine came not from a Web site discussing John Norman’s Gor books, but from the live stream page of KMOX radio, a CBS affiliate in St. Louis, where one of its ads tried a JavaScript exploit on me.
  • You have no control over quality of the third party code.
    No matter how much or how little you test your Web site or application, you can rest assured the third parties test their stuff less (even if that is, in fact, a negative number). Many of the JavaScript errors I see when careering around the corners of the Internet stem from missing objects associated with third party code. This might not adversely impact your Web site, but we don’t like to deal with might not as a plan of action in QA, do we?

I realize this is a repeat of what I have said early and often throughout the almost five (!) years of the blog, but the above article gave me an excuse to repeat it again.

(Link via Scott Barber tweet.)

You Don’t Let Your Developers Do It, And Here’s Why

Tuesday, February 14th, 2012 by The Director

You, ungentle QAer, don’t let your developers throw up pages that instruct the user not to close the window or click the back button, right? Of course not. You’re not an amateur.

But here’s a good blog post taking them apart anyway.

Sometimes Real Life Fails a Load Test

Thursday, January 19th, 2012 by The Director

The application could handle it. The business behind the application? Not so much.

You need to be careful about what you promise—especially when you make a promise on social media.

This adage is ringing loud and clear for Toronto-based Timothy’s Coffee. In an effort last month to grow its Facebook fan base, the company ran a promotion saying that anyone who “liked” its page would receive four free 24-pack boxes of single-serve coffee. As the Toronto Star reports, this was rather generous, as these boxes retail for over $17 CAD each.

A contest aggregating site picked up the promotion and, as you can imagine, responses poured in, reports the Star. Problem is, the stock of product was depleted within three days of the launch, yet Timothy’s still sent emails telling people their coffee was on the way.

The best part? This is an EPIC WIN! for Timothy’s Coffee’s interactive agency, since a promotion so successful that it makes headlines is AWESOME! It’ll be in all the presentations from here on out.

As always, you have to remember that the little numbers on the screen match up with numbers somewhere else in real life. And your application can be one hundred percent consistent with itself, but if its business rules and limits do not align with the real life it represents, it’s a worthless application.

(Link seen via tweet, but I forget whose. Sorry.)

An Oversight That Never Goes Out Of Style

Wednesday, December 28th, 2011 by The Director

Ah, the old “insecure images on a secure Web page error”:

It's like a classic songbook standard of Web site errors

That one is classic. And ongoing on oh so many sites that try to use their insecure templates on their secured Web pages.

Remember the Day QA Destroyed The World?

Tuesday, June 14th, 2011 by The Director

A classic scene from WarGames:

Fortunately, they did not have anyone testing the WOPR. I mean, seriously, number of players zero? Anyone reading this blog would have caught that and made them fix it, and blammo, nuclear war.

Who Proofreads Your Text Files?

Tuesday, April 26th, 2011 by The Director

If you’re anything like Pinnacle Systems, the answer is either “Nobody.” or “The same person who wrote it, using the same rules of !grammar.”

Grammar errors in a readme file
Click for full size

Your organization does realize that these are written communications akin to actual documentation, doesn’t it?

Oh, who are we kidding, of course they don’t. They leave it to developers to jot something down here and expect it will never be seen.

Why don’t you snoop around and see how it’s done? At the very least, it will make you look busy. At the very best, you can help further mask how functionally illiterate many of your co-workers are (or cover better that things are not written by native language speakers).

One Fewer, But Not The Last

Thursday, April 14th, 2011 by The Director

Ladies and gentlemen, a computer user, anecdotally:

Just a quick note of thanks for your recent comments concerning iPad use by seniors. I just gave my 88 year old Dad an iPad (original, WIFI only) for his birthday, in an effort to replace his aging & very limited WebTV. Success beyond all expectations! He very quickly mastered the basics of email, browsing, and YouTube videos….

In the second decade of the 21st Century, this gentleman was using WebTV to access the Internet.

I mentioned it in passing in the latest Two Minute QAte, but WebTV users still exist. You need to remember that people, especially people who don’t work with computers all day, use outdated technologies that you probably gave up eight years ago, and you must account for these people in your planning. Even if this accounting is merely deciding you won’t support them.

Although it would be nice if you’d programmatically let them know that, too, before they’re using their rotary phones to reach out and touch your customer service representatives.

Does Your Innovative Interface Suit Your Users Needs… Or Your Needs?

Wednesday, January 26th, 2011 by The Director

I got this new Renoir calendar for the office (what, you expected I would only like the artwork of Derek Riggs?), and I’ve noticed that it has escaped the usual bourgeois constraints of comprehensible design. Behold:

The Renoir calendar, calendar portion
Click for full size

You see, they “solve” the “real estate” problem of having a month comprise parts of six discrete weeks not by putting the final couple days on the bottom row with the preceding week, but by wrapping them to the top. You know, where you would not look for them because that’s the past. But the solution solves their problem.

When your designers break the mold and try to do something different, something that’s never been done before because now they have THE TECHNOLOGY to do it differently or merely because they’re just interns fresh from the second decade of the 21st century’s college of design pablum in their heads, you have to consider: Will my users understand this? Does it make their experience better? Or is it just something my designers want to do.

That leads me into some of my pet peeves:

  • Placing the control labels into the controls. Especially irksome when I tab into the control and the label disappears.
  • Reversing the normal button order of alert or confirm boxes. I hate when it’s Cancel/OK or No/Yes. Yes, I understand Macintosh has always done it that way, but it’s not the way I understand it. If I’m only half paying attention, which I usually am because I’m paying more attention to the all-woman Iron Maiden tribute band playing in the background, I’m going to do it wrong. Your application should be helping to keep me from messing up.
  • Fields that are out of common order. You’ve seen forms where the Confirm Password edit box is not right after the password edit box or where the fields in an address are out of order. Okay, these are not so much design decisions, but sloppy oversights caught with no QA.

Bottom line: If you’re going to break out of the traditional metaphors your user has experienced for years or decades, you’d better make sure your application is doing it for your user’s sake, not for the bragging rights your designers will get for doing something outrageous or extreme.

Is This Your Audience?

Tuesday, January 18th, 2011 by The Director

Just because someone owns a computer that could handle the moonshot in 1969 doesn’t mean he or she owns a computer that can handle the extent of your cutting edge design genius:



If you’re building 3-d Flash immersive environments to sell cat food, more often than not, you’re trying too hard. Don’t only think of what all you can do with your high-end Macintoshes there in the office. Remember, Roberta is out there, limping along on a low end Windows XP box and trying to get a coupon to save her fifty cents on her next purchase of her product. If she can get it.

So, Do You Test Your Meta Content?

Tuesday, August 3rd, 2010 by The Director

When you’re building a Web site or application, do you check your pages’ meta content?

Neither do the people behind the MyFox channels’ Web sites like MyFoxPhilly or MyFoxNY:

Click for full size

Remember, those meta things show up a lot of places. People see it in search results, social networking site summaries, RSS, and so on. If you’re misspelling something or dumping a null in it, that’s gonna leave its mark.

Would it hurt you to view source now and then? I think not.

Rotation or Revolution

Thursday, May 6th, 2010 by The Director

This article on career rotation reminds me of a point.

In Big, the hit movie from the late 1980s, star Tom Hanks rises from a clerk in data processing—that’s what technology was called back then—to become vice president of product development for a toy company. That quantum leap in status and pay took him all of a week to pull off. Some would-be fast-trackers might call that the ideal job rotation.

Some companies have always encouraged ambitious employees to rotate out of their discipline—technology, finance, marketing, operations, etc.—and into a different department, often one in which they’d have to push themselves to succeed.

The rationale is simple: By seeing how other areas of the company operate—getting the proverbial big picture—an employee becomes more valuable, and the organization as a whole gains. Six to 18 months in a new assignment arms an employee with additional knowledge and layers of skills.

That career advice is more geared to people in big corporations who aren’t in tech jobs but managerial or other non-tech components (business analysts, project managers). Nobody is going to take a technical writer and try him out in QA, for example, or give him 18 months to taste development. However, rotation is important to keep your peeps, especially your QA bunnies, from burning out.

Let me explain. No, there is too much.

One of the shortest postings in my career came when I was put on a QA team on a long deathmarch of a multimillion (and I mean two) and multiyear (and I mean like four) project to develop a custom piece of software for a client. I joined the team some months in, when they had a mostly working Java desktop application (perish the thought! because the application surely perished). I started testing an area of it and tearing it up. The client didn’t like this, didn’t like that, wanted more of that, and altered the specs so that my employer had to change it. I spent nine months essentially testing the same features of the same application and often logging the same issues when I left.

Don’t do that to your testers. Let them see different things, different projects. If you swap them around, they get more experience with the gestalt of the application/business/et cetera as well as learn new techniques, technologies, and music fitting for QA when they work with different people.

I’m Such A Harpist, I Ought To Be In The Symphony

Wednesday, April 28th, 2010 by The Director

Another Web study shows that IE 6 is still alive and thrashing on the Internet especially in corporate America :

Security experts, industry analysts and even Microsoft recommend that IT departments upgrade Internet Explorer 6, yet new research shows that while there may have recently been a mock funeral for the aging browser, IE6 is still around and doing well, especially during standard business hours.

Chitika, a search-based online advertising network, conducted a study recently to learn the hour-by-hour market share of some of the leading Internet browsers. The study showed that IE6 ranked fourth among all browsers, grabbing 13% of usage during what many consider peak business hours.

I’m about to go into a project where I pressed the client to get a list of its client’s browser requirements beforehand. Shockingly, to them, the ultimate client used IE6. So I’ve pressed the development team to look at it in IE6 before turning it over to me for testing. If all goes according to prophecy, and by “prophecy” I mean the way it usually goes, they won’t, and I’ll have to load the defect tracker with IE 6 issues.

Just because Google said IE 6 was dead does not make it true.

(Link seen on Andrew Richards‘s Twitter feed.)

Think Of It As Decals On Your Fuselage Of Programs You Crashed

Wednesday, February 24th, 2010 by The Director

Steven Den Beste finds a common error with programs that write their icons to the Windows system tray:

Every time I start playing a new file, it spawns another icon in the tray. There’s only one copy of it running, and if I run my mouse pointer over them then all the phantom icons will disappear.

Let me put on my developer hat here: That’s not a bug, it’s a feature! Yeah, it tells you how many files you’ve played since you’ve moused over the system tray! I’m marking the defect RESOLVED: NOT A BUG!

As one of his commenters mentions and my experience indicates, this happens sometimes when low rent applications ab-end. And I include Yahoo! Messenger in the low end category.

Which brings me to a good testing point: So, what happens when you kill your desktop application from the task manager? Does it leave connections on the database open? Does it leave stray icons? Try it and find out. You might like it better if you know the UNIX term for it: kill.

Jerry Pournelle on Fly-by-Wire and Programming Languages

Monday, February 22nd, 2010 by The Director

Speaking about the Toyota software problems, Jerry Pournelle diagnoses the root of many quality problems in software:

When the computer revolution was beginning, there was a concerted effort to develop theories of computer languages. Two major champions of language reform were Niklaus Wirth** of ETH (Zurich, the Swiss Federal Institute of Technology) and the late Edsger Dijkstra (eventually held a chair at the University of Texas in Austin). Dijkstra spent much of his life developing theories on how to “prove” programs. They and some others were largely responsible for the movement that induced the Department of Defense to develop Ada, a strongly typed and highly structured language with some similarities to Wirth’s Modula languages. (The last time I discussed it with him Wirth did not care for Ada, in part because it became too complex with too many “features” and in part because he did not approve of exception handling — and that is one argument I’m not going to get into.)

More on all this another time, but my point is that in those times there seemed to be a lot more concern with languages, and with building languages that required good programming practices. In the various Wirth languages starting with Pascal the goal was to have the compiler catch incipient bugs: it took longer to develop a program that would compile, but once it did, it was likely to do what you expected it to do. Unfortunately the computer hardware of the time wasn’t up to huge programs in strongly typed and highly structured languages; it took a long time to compile a new addition to a program. The programming world turned to C and its derivatives, and in the early days a C compiler would compile almost anything, including very tricky uses of pointers and type changes.

I don’t know what language Toyota has used to develop its drive by wire programs, but I would bet reasonable sums that it wasn’t Ada or one of the Wirth languages.

To make it easier for people to become developers, they made it easier to write software. To deleterious effect.

By the way, be sure to use the word deleterious in a sentence this week. Vocabulary is a weapon.

Designers Don’t Have Enough Stakes To Kill IE 6

Thursday, February 4th, 2010 by The Director

Here’s an e-mail that might give hope to Web designers and developers in the world, probably written by a Web designer to boot:

IE 6 is immortal!
Click for full size

I suspect a Web designer wrote that subject line because he or she left in an extraneous “this” and misspelled, “Yay!”

I can understand the glee.  Hopefully with Gmail dropping IE6 support, they can, too!  If they even think about anything but Safari or Chrome.

However, as a reminder, IE 6 has a 20% share of the browser market in this January of the year of Our Lord 2010 according to Net Market Share.  More than Firefox.  5 times that of Chrome.

If your site or application doesn’t handle it, you’re going to strand a lot of users.

Now That You’re Dating Checks Correctly

Monday, January 18th, 2010 by The Director

Two weeks ago, an event occurred that altered the fundamental way we describe our locus within the space-time continuum.  That event, the New Year, means that any Web site to which you added content since then needs to have an updated copyright date:

I'm so 2008, you're so 2000 and late.
Click for full size

 If you’re working in PHP, such as a blog, here’s a PHP script to make it dynamic.

Another thing to check is for any recurring contests on your sites, such as stories that you ask users to share, to make certain that your terms, conditions, and rules extend to the new calendar year.

Don’t Be Stupid

Monday, February 9th, 2009 by The Director

You remember that Google problem that flagged the whole Internet as malicious?

Shall we count the myriad failures inherent in it?

  1. They trusted administrators to be infallible. The process or tool they use to perform the updates didn’t question whether the user really meant to flag the whole Internet. It did not validate on obvious problems. If it’s like anyplace I’ve ever worked, the administrative tool is a pasted together bit of interface and workarounds, rife with problems and untested or undertested because only administrators would use it.
  2. They didn’t test it immediately. The “on-call site reliability team” took care of it. That sounds like me that either an automated process dialed some pagers or a help desk person got a phone call. They probably ought to have someone check that right away, hey? Nah, they’re Google. Everything they touch turns to good.
  3. A variety of sources show that Google blames its data provider initially. That is a sign of hubris of the commonest order. Maybe they shouldn’t have been so hasty to lay blame before understanding and fixing the problem. On the other hand, Google did fix it quickly. Some organizations spend more time on the casting aspersions part of the program, sometimes foregoing fixing the problem entirely.

If Google can make these mistakes, so can your company. The key is not to use that as an excuse when your organization blows it (“Hey, it’s okay, even Google does it!”). You have to learn from these mistakes and make sure your company doesn’t trust its administrators and tests things the minute changes are made.

Understanding Your Dev and Project Management Team

Tuesday, January 6th, 2009 by The Director

Story in the New York Times: Some Protect the Ego by Working on Their Excuses Early:

Every ugly exam score, blown deadline and failed project provides the opportunity to try out new excuses. It was a blowup at home. A sick cat. An emergency at work.

Not to mention the roadways: if only they hadn’t been so icy.

This kind of talk is so familiar that most people quickly dismiss it, even when it comes out of their own mouth.

This is one reason that genuine excuse artisans — and there are millions of them — don’t wait until after choking to practice their craft. They hobble themselves, in earnest, before pursuing a goal or delivering a performance. Their excuses come preattached: I never went to class. I was hung over at the interview. I had no idea what the college application required.

You know, dev teams and companies I’ve worked with often have this sort of self-limitation built into them.  You get hours and hours ignoring good quality practices like tight specs, proper communication, reasonable timelines, and tolerable levels of testing, and then they make up that time with lessons learned meetings at the back end compiling useless rationalizations for one-time events and confluences of circumstances that caused this failure, this time.

Then they’ll do the same thing the next project.  Or the next company will only do as much as the last company, because the other companies seem to tread water with known issues in their products.

On the plus side, they all get paid for the self-defeating, and will get paid in their next, higher, positions of self-defeat.

(Link seen on Instapundit.)

wordpress visitors