Scott Bush

Recently I worked on a prob­lem at my job whose solu­tion involved the use of PDF files (and PHP and other cool stuff that I’ll post about soon). Unfor­tu­nately, this process exposed me to some poor soft­ware design and hor­ri­ble customer-service issues from a com­pany I usu­ally like and whose prod­ucts I respect.

A bad soft­ware feature…

Admit­tedly, Adobe’s soft­ware soft­ware has some prob­lems, but I’ve per­son­ally not run into them until now. The “merge to PDF” func­tion pro­vided by Acro­bat Pro­fes­sional 9 (for Win­dows; I’ve not tried this on a Mac) for use in Word’s mail-merge fea­ture has a glar­ing over­sight: it doesn’t pro­vide a way to name the sequenc­ing of the result­ing files. An exam­ple: say you are mail-merging 50 let­ters to PDF. You enter “DeansLet­ter” as the base name for the PDFs but end up with a folder full of PDFs that are named “DeansLetter01001,” “DeansLetter01002,” “DeansLetter01003,” etc.

What’s the big deal, you ask? Though it’s annoy­ing you can’t spec­ify the sequence’s start­ing num­ber or the num­ber of dig­its, the huge prob­lem lies in cre­at­ing a large num­ber of PDFs. Strangely, Acro­bat uses some seem­ingly arbi­trary group num­ber, fol­lowed by a three-digit sequence. When gen­er­at­ing over a thou­sand let­ters, as we did, that group num­ber and sequence var­ied so that sort­ing the files by name resulted in a list that was out-of-order rel­a­tive to the data file used in the merge. Put sim­ply: a very large data set in alpha­bet­i­cal order by recip­i­ent last name gen­er­ates a list of mail-merged files that, when sorted sequen­tially, aren’t in alpha­bet­i­cal order.

This of course, is awful. And so eas­ily avoided! Adobe could have sim­ply appended a num­ber begin­ning at 1 increas­ing from there. That way, at least, a nat­ural sort algo­rithm could keep them in order. Or smarter yet: iden­tify the num­ber of items in the data set and append the proper num­ber of lead­ing zeros. So a set of 50 items would begin at 01; 125 items would begin at 001; 13,000 would start at 00001, etc. Easy. But it’s as though Adobe’s engi­neers tested this func­tion with a hand­ful of records. “It works,” I hear them say “merge-to-PDF func­tion: check.” Sure, tech­ni­cally it works… but it’s inel­e­gant and doesn’t work with a lot records, which surely is a com­mon use case for this func­tion. Where is the user test­ing that a great soft­ware com­pany like Adobe should rou­tinely employ? It’s hard to imag­ine a real user not men­tion­ing some­thing like this.

Even Adobe’s own online help is barely coher­ent about this function’s use:

To name the PDF that will be cre­ated, type in the Spec­ify PDF File Name box.

Note: The PDF will be named using this text plus a series of num­bers. For exam­ple, if you type JulyLetter in the Spec­ify PDF File Name box, the mail-merged PDFs might appear as JulyLetter_0000123, JulyLetter_0000124, July Letter_0000125, and so forth.

“…a series of num­bers…”? “PDFs might appear”? Tech­ni­cal doc­u­men­ta­tion should never include “might” when describ­ing a result of a soft­ware oper­a­tion. And I can assure you that the num­ber­ing sequence we received didn’t match the help file’s descrip­tion. Terrible.

…led to an even worse customer-service experience

Try­ing to be a good cit­i­zen, I left a very com­plete (and polite!) expla­na­tion of the issue (includ­ing a detailed exam­ple) we expe­ri­enced on Adobe’s com­mu­nity help forum. A day later I received a mes­sage from Adobe’s forum mod­er­a­tor telling me my post was a fea­ture request, not a com­ment, and there­fore had been removed. They unhelp­fully sug­gested I re-post it on one of their fea­ture request forums instead. Amaz­ingly, they did not include my post in the e-mail mes­sage, and of course was never posted to the page; it was gone. I’d spent over 10 min­utes writ­ing a help­ful post that they essen­tially deleted, yet they expected me to re-type it some­where else? So I responded—again politely—asking for a copy of my post and explain­ing why I wanted it, but I never heard back. That’s hor­ri­ble. This “ser­vice” cost them a lot of brand loy­alty from me and earned this neg­a­tive press.

So what is the pur­pose of this post? Not just to com­plain because that never solves any­thing. Instead, I hope that it inspires soft­ware devel­op­ers to test their fea­tures with “edge cases,” (like very big or very tiny data sets), not just the typ­i­cal cases. Any­one mod­er­at­ing a forum should also take note to include a customer’s ini­tial sub­mis­sion in their response (though I know most already do, which is why Adobe’s fail­ure to do so is so frus­trat­ing). And, finally, if some­one at Adobe hap­pens upon this post, maybe they’ll do some­thing about to fix that merge-to-PDF num­ber­ing fea­ture. One can always hope, right?

Far be it from me to com­plain about bank­ing these days, since it’s pretty darn easy. As a kid, I used to walk a block to the local branch and deposit my change once a week. These days, years go by with­out me set­ting foot inside a bank thanks to auto­matic deposit, online bank­ing, and of course the ubiq­ui­tous ATM.

Why do I have to keep select­ing English?

ATMs cer­tainly rev­o­lu­tion­ized bank­ing for both the banks (reduced man­power costs and increased fees) and cus­tomers (ease and avail­abil­ity of bank­ing and if you’re not care­ful, increased fees). I’m a big fan of ATMs in gen­eral and US Bank in par­tic­u­lar, but there is one glar­ing user expe­ri­ence over­sight that I sure wish they’d cor­rect: my lan­guage preference.

This is an image of the ini­tial screen on my US Bank ATM. I see it every time I use an ATM—every time. “What’s the big deal? Man, you like to com­plain about every­thing, don’t you?” I can already hear you say. While it’s cer­tainly true that a sin­gle click or but­ton press is not gravely impor­tant issue, it is worth dis­cussing from a user-experience stand­point. Why? Two reasons:

1. It affects every user of the sys­tem — I may be the one writ­ing about it, but I’m cer­tainly not the only one who’s annoyed by it. It’s a few sec­onds wasted with each trans­ac­tion, mul­ti­plied by dozens or even hun­dreds of trans­ac­tions per ATM per day. That’s a sig­nif­i­cant amount of wasted time.
2. It’s com­pletely cor­rectable — I can think of at least three ways this issue could be resolved that shouldn’t be ter­ri­bly dif­fi­cult to imple­ment (though I real­ize the true com­plex­ity of a sys­tem might not obvi­ous to its end users).

For these two rea­sons alone US Bank should inves­ti­gate resolv­ing this issue. (And while they’re at it, they could do the same with the “Do you want a receipt for this trans­ac­tion?” ques­tion.) With acknowl­edge­ment again to the com­plex­i­ties of a sys­tem I’m not famil­iar with, I’ll go out on a limb and say this sit­u­a­tion could eas­ily be resolved with a sim­ple account pref­er­ence: Eng­lish or Span­ish (and per­haps other lan­guages in the future). Ah, but how to retrieve a user’s pref­er­ence before the user is ver­i­fied with their PIN?

• Store pref­er­ence in the card — This is prob­a­bly the most dif­fi­cult option, as it would require some data stor­age on the card. Whether that’s a sim­ple flag bit (“on”, the default, could rep­re­sent Eng­lish; “off” could rep­re­sent Span­ish) or a more use­ful setup (such as one that sup­ports mul­ti­ple lan­guages and other pref­er­ences) would depend on the card’s capa­bil­i­ties. Plus, get­ting the data onto the card might require it be run through a mag­ne­tiz­ing device at a branch. It might also require changes to the ATMs them­selves to enable them to read this pref­er­ence infor­ma­tion from the card. Imple­ment­ing this solu­tion would likely be complex.
• Store pref­er­ence with the account — The ATM knows your account number(s) when it ini­tially reads the card, as that is stored in the mag­netic strip. A solu­tion could be to have the ATM query the bank’s data­base to look up the pref­er­ence stored with that account. It might take a few moments, but it would cer­tainly be less time than it takes to present a lan­guage choice, have the user read/recognize it, and select their choice. The lan­guage pref­er­ence could be set (or changed) through online bank­ing or in per­son at a branch, or per­haps even at the ATM itself.
• Avoid choice alto­gether — One solu­tion would be to sim­ply avoid requir­ing the user choose a lan­guage by dis­play­ing both Eng­lish and Span­ish together, as you often seen on food labels (and indeed on the instruc­tions on the language-selection screen shown above). This approach, though, suf­fers because of the addi­tional space required to dis­play every­thing twice; and it cer­tainly won’t scale to three or more lan­guages. This could be ame­lio­rated by rely­ing more on images or pic­tograms instead of words—and numer­als are the same in both lan­guage. But even this has prob­lems: small images won’t dis­play well on ATMs’ small, low-fidelity screens; and choos­ing mean­ing­ful, cross-cultural images to rep­re­sent ATM selec­tions cre­ates a headache greater than the prob­lem it would solve.
• Do noth­ing — It’s also pos­si­ble (and prob­a­bly likely) that this topic was dis­cussed and US Bank exec­u­tives decided that despite blog­gers like me talk­ing about it, the exist­ing solu­tion is best. It allows both Eng­lish and Span­ish speak­ers to select their pref­er­ence and didn’t require any changes to their back-end systems.

Except­ing the last one, any of these ideas—or one I’ve not even thought of—could solve this user-interface annoy­ance. Do I think it’ll actu­ally hap­pen? Prob­a­bly not. Banks have a lot of other issues to deal with these days and hon­estly, I’d rather have them pro­vide greater returns and do other impor­tant banking-type-things. With that said, there must be some enter­pris­ing young soft­ware engi­neer at the bank who could get this done and quickly rise through the ranks to become the youngest vice-president of the ATM divi­sion in the bank’s history!

After over 8 years, we’re sell­ing our condo in Ken­more, WA. Never one to rest on my lau­rels, I cre­ated a web­site to high­light the incred­i­ble pho­tographs taken by our good—and extremely talented—friend Dylan Greene. What started out as a sim­ple site to dis­play some pho­tos quickly grew into an oppor­tu­nity to flex some web-development muscle.

Take a look a the site (and if you’re inter­ested in buy­ing, let me know!): http://scottbush.net/condo/

(more…)

The Uni­ver­sity of Washington’s Office of Infor­ma­tion Man­age­ment (OIM) invited me to be a guest blog­ger on their On the ROA blog*. My post, titled “One developer’s per­spec­tive on the SWS’s course search resource,” appeared there today. It was an honor to be asked to write a sum­mary of my expe­ri­ences lever­ag­ing the UW’s Stu­dent Web Ser­vices to build a web application.

(more…)

This beauty of a sign caught my eye while on a walk in Seattle’s “Tan­gle­town” neigh­bor­hood (oth­er­wise known as just south­west of Green­lake) recently. I just had to share it.

What I love about this sign is its absolute ded­i­ca­tion to its pur­pose. There’s no mis­tak­ing what’s going on here (unlike the “drug-gun” sign I wrote about recently). The pic­tured crab is, in no uncer­tain terms, lost! The lit­tle details in the sig, like the crab’s name—Oliver, of course; what else would you name a crab?—and the “10$” reward just scream of a child’s sin­cer­ity. I can just imag­ine a dis­traught six– or seven-year-old stand­ing next to her par­ent at the com­puter writ­ing up this sign, which would soon be plas­tered over nearly every tele­phone pole in the area.

(more…)

Who would have thought a pro­hi­bi­tion on brown M&Ms could be a safety measure?

In the open­ing of this weekend’s episode of This Amer­i­can Life, host ira Glass dis­cussed a line from rock group Van Halen’s con­cert rider. The line, requir­ing that a bowl of M&Ms be avail­able back­stage with all the brown can­dies removed, is infa­mous for typ­i­fy­ing rock stars’ demand­ing needs. Ira’s talk with another, less flam­boy­ant rock star reveals that the color-specific M&M require­ment is less about Van Halen’s finicky taste in candy and more about safety. In short, it’s a great exam­ple of design mov­ing beyond form and becom­ing func­tional. In this case, it ensures the venue’s man­age­ment has read and fol­lowed the band’s strin­gent require­ments for its exten­sive gear, light­ing, and speak­ers for their show. (Lis­ten to the open­ing sequence for the rest of the story.)

It’s the design of the rider that strikes me as most inge­nious. By work­ing in a per­sonal request deep among the para­graphs of con­cert spec­i­fi­ca­tions, the band would know instantly whether the rig­or­ous safety require­ments  in the rider had been paid atten­tion to. Brown M&Ms in the bowl = unread rider; a candy-coated canary in the coalmine. Sim­ple, ele­gant, and effec­tive. Now that’s good design. If you like, you can read the whole rider.

(more…)