This post is about something specific, but the concepts are general:
When presenting a license to an end user, make it fully accessible.
What does this mean? A couple things, at least:
Allow text to be selected. I'd like to be able to copy and paste either sections or the whole content to another format, for easier reading, making notes, bookmarks, etc.
Make it easy to print. Sometimes, it's just easier to read things in hard-copy. Especially if one wants to take notes, read things somewhere quiet and distraction-free, or the like.
There are probably more, too. And certainly Apple has other issues with the way they do licensing. For example iTunes. Every single time an update to iTunes comes out -- or at least it seems this way to me -- the user is forced to agree to a license again.
Presumably, the license has changed only a little bit, if at all. So why do I need to read pages and pages of license agreement each time?
Well, why do I, you may be asking? Because in theory, clicking "agree" means that I have done so. If they would provide me a summary of changes, this would be so much easier to do. Better yet, stop presenting it except when it's changed, and try not to change it often.
I could go on and on, and it's not just Apple... but Apple being a company that I'm a frequent customer of, and having some poor policies in my mind, they're the top of my list right now of annoying licensing practices.
Steve Jobs or someone: Please put some attention on this, and get your lawyers to work on making this more user-friendly. Don't worry, they won't mind too much: it's more work for them. :-P
A lot of places are outsourcing support, these days, or so I keep hearing (and from time to time having evidence of).
And I just recently had a support experience where the software to support my on-line real-time chat was outsourced, even though the actual support person was not. But as it happens, the experience was problematic in other ways, that I won't bother going into -- another person at the company was able to clear things up quite nicely. My point of telling you all this, though, is just to point out why I came to the following conlusion:
Skilled support staff is better than non-skilled support staff
This probably especially applies to outsourced support staff, as I imagine they're most likely to be following a script, rather than actually understanding the problem(s) that customers are facing.
And here's the reason:
Someone who actually has a chance of understanding the customer in detail, is going to be achieving "habit 5" from the seven habits of highly effective people[1] -- and most importantly, in my mind, not even just the understanding part of it, but that the customer feels understood. Because feeling understood opens you up to then having a good interaction with someone, instead of just battling to try to get your point understood. (Granted, the customer can try to apply habit 5, but in my experience, it's really really hard to do with someone who's trying to read from a script.)
So yeah, to my mind, having scripted support (outsourcing or no) is a recipe for frustrated customers... which of course means customers who are that much more likely to become former customers, and that much less likely to encourage others to become new customers.
So, hire the best in your support staff, and train them well -- on the tech side and on communications. It's better for the customer, and, in the long run, better for your organization, as well.
At least that's how I see it.
[1] Note: I'm linking to the wikipedia article, instead of a direct link to the book, because, while I think Covey's material is great, I'd really prefer that you didn't buy his book. He's an active member of the LDS Church, which presumably means he tithes to (or otherwise financially supports) that organization, and I have a strong desire to avoid helping them out in any way (which is the subject of another post -- I'll try to remember to update this post with a link to it, if/when I ever write it).
Last night, I witnessed a car accident. It was a minor accident, a so called (and literal) fender bender. A large black pickup truck, with Idaho plates, struck a Yellow Cab. My first form of witness was hearing a bang. I turned my head, and looked, and saw and heard a second bang. The cab was rear-ended. Twice, technically.
I was half a block away, waiting at a bus stop. I started walking towards the incident. The truck was clearly at fault, and I'm a believer in being the type of witness who will go and report what they've seen, to help out a wronged person, whatever the situation. So I walked closer, and got out my phone (the only camera I had with me at the time), and took a couple of pictures, and making mental notes of what had happened. I then switched to video mode, so I could also make some actual recorded notes, via speech, about what I'd seen. While I was recording, the driver of the pick-up truck drove away. It had just escalated into a hit-and-run.
I crossed the street, to check in with the cabbie (here's hoping that's not a derogative term -- I certainly mean it only as a description of their occupation at the time). I was received with an apparent wino, asserting that he'd just gotten a ride from down the block. I didn't realize at the time, but was later assured by another witness (my girlfriend, Laura), that this person had gotten out of the pick-up truck. I could go into the speculations we had about why the guy was picked up, but making assumptions about that would be wrong in ways only incidentally related to the main thing I want to talk about here.
I had photos. I had video. It had been a hit-and-run. Sadly, I did not have the license plate -- I didn't get a clear picture of it (though I did get an unclear picture of it -- I was trying), and I hadn't made any other note of it, other than a mental one of the state.
Meanwhile, the wino (there are assumptions here, too, but I'm going to go with that as the best description I can come up with at the moment for this person) was getting up in my grill, which was interfering with my ability to check in with the cab driver, which was my first priority. I told him I had no business with him, and to let me do my think. In clarity of hindsight, I wish I'd gotten more of his story, or perhaps even a photo of him. What I did do, though, was to move on to my 2nd priority: Calling the police.
So I dialed. 9-1-1. I described to the dispatcher what I had just witnessed. I answered some questions, gave some pertinent details to the "radio" person (i.e. someone actually dispatching details to police, rather than the operator I was initially speaking to), and then was told (by the original operator), after a few more questions, that a car would be at my location shortly.
And there was. A police officer (whose name and/or ID number, alas, I didn't think to get -- I'll freely admit that I'm not always the most prepared thinker in these situations, though hopefully I'm learning to be better as I go) arrived, talk to the cabbie, talked to me, talked to Laura, got IDs from each of us, looked at my video evidence, etc. Another officer arrived at one point, had a brief interaction, and then went off in the last-known direction of the offending vehicle.
Another cab driver, apparently (and later ostensibly) a friend to the one who had been struck, arrived on the scene. The police officer got into his cruiser and was making notes. He eventually came back out, gave Laura and I back our IDs, and let us know that we were free to go. The other cabbie at that point asked us where we needed to go, offering to take us, apparently in thanks for our assistance.
The first cabbie asked for our contact information, and it was agreed (I'm pretty sure -- hopefully the struck cabbie was actually in agreement with this plan; I never actually spoke with him terribly much, alas) that we'd give it to the other cabbie, as we drove. (Meanwhile, the police car raced off with lights going shortly after we pulled away. In pursuit of the driver, who had been caught by the other police car, I hoped... though really, I'm guessing that it's more likely that it was in response to an unrelated call. Who knows?)
And we did do that. Laura and I each wrote our names and numbers down on a piece of paper.
Which brings us, almost, to the real point of this story. This second cabbie (whose name I'll keep from reporting here, for reasons which will soon be apparent) and we had a little conversation in the cab, and he thanked us for our help, and we thanked him for his, and he dropped us off at home.
This morning, a phone call came in. I had stayed up late (for completely unrelated reasons), and so even a late-morning call was (literally) a wake-up call. An unknown number, and I was still half-asleep, so I didn't answer. A little while later, though, the same number called again. And then the same number called Laura. I was starting to be more awake at this point. Neither of us had answered, but clearly they were calling specifically for us, or they wouldn't have called those two numbers in such quick succession. So I sent back a text message, asking who they were, and saying to leave a message. And after sending that, it clicked: I know who this is -- at least roughly: It's either one of the cabbies, or someone from the police (but no, they'd have left a message), or someone related to that incident.
And so when the phone rang again, I answered it. And here's where the meat of the story comes in. It was the second cabbie, the one who had given us a ride home.
His English was imperfect, and so are cell-to-cell phone calls (I'd given him my home number, but that currently forwards to my cell phone), so it was a bit difficult to understand what he was saying. With some repetition and some effort on my part to understand him, though, I eventually figured out (and here's the crux of it):
He wanted me to not report anything further to the police, or, especially, to Yellow Cab. The other cabbie, he told me, had decided that he wanted to just handle it himself. He was unhurt, and it would be less expense and less hassle if this did not go on his record, did not get reported to the cab company, and did not get reported to his insurance. Even though he was clearly not at fault, if the cab company or his insurance found out about it, it would be points on his record, increased premiums, and the hassle of reports to fill out.
I believe this is wrong. Let me be more specific: I believe that this decision, upon the part of the cabbie, was understandable but unfortunate; I believe that the fact that he was motivated to make this decision -- by what I presume is the very real expectation that it would cost him time, money, and hassle -- is wrong. He should, I deem, have had very little if any reason not to give a full report, and various reasons to give such a report.
This is my assertion. To have an insurance company and/or a cab company that holds cab drivers (or any drivers) to account for an incident which can clearly be shown to not be their fault: this is an injustice. And this I am railing against, and hence the reason for this blog post.
And yet I feel somewhat trapped, as I genuinely do believe that if the incident was reported, that it would in fact do harm to the livelihood of this driver. So I don't want to say all I know. What I instead am doing, is writing this blog post. And I implore any readers of this, and I quite possibly myself will, contact yellow cab, and ask them to change their policies, such that incidents such as this one are not something that their drivers are inclined to keep quiet. Because whatever else may or may not be true, one thing is certain: There is a driver out there somewhere who fled the scene of an accident that he (and I did see that it was a he) was at fault for. And for a variety of reasons, this is unacceptable behavior. I don't know if this person was caught or not. I'm guessing not. There are a lot of turns one can make in the minute or two that at a very minimum had transpired between when he left the scene and when I got to the point of talking to the radio dispatcher, let alone however long it took to get the message out. Then again, radio signals travel faster than any vehicle, so there's some vague hope.
At any rate, I believe that a wrongness exists, and I've come to believe in the idea, from Barry Mann et al, that "none of us are free, if one of us is chained". This cabbie is chained, figuratively, from the freedom of doing the right thing, and making a report about a wrong that was done. And so I will not take the action of "if you don't say it's wrong, then that says it's right." This is wrong. I encourage you to join me in efforts to "get the message, send it out loud and clear".
But really, Solomon Burke sings it so much more poignantly than I can write it:
None of us are free. Giving people reasons to avoid reporting wrongs is, itself, wrong. Make it stop.
I wish everyone (especially people maintaining libraries for others to compile against) would use -Wall -Werror (and maybe even -pedantic and other such things) in their Makefiles for things. It's really quite simple, just find the line that looks like:
CFLAGS = -g # and/or whatever else
and add -Wall -Werror to the end of that, like:
CFLAGS = -g -Wall -Werror # and/or whatever else
Oh, and I've recently learned of another one, to enable "extra" warnings, and a nicer way to put them into your (GNU) Makefile:
CFLAGS += -Werror -Wall -Wextra
Get your compiler to force the issue of fixing your warnings, so someone else won't end up stuck with them. You know your code better than someone else will, so you'll be much better at finding the right fix to the warning.
I'd give extra bonus points to anyone adding these to default configurations (default option for gcc? Apple make these the default for Xcode, etc.). There might be downsides to that, but... oy. So many projects have so many warnings, many of which (though I'm sure not all) are likely bugs that could be fixed if people would warn about them.
[Note: this article was edited 2011-02-28 to add new content, and re-shape some of the existing content.]
In my past life as a systems administrator and tech support person, one of the terms I remember hearing about was "Voodoo sysadmin" -- which I basically think of as doing something to a system when you're having a problem in a vain and superstitious hope that it'll fix the problem, without really understanding what's going on. (An old acquaintance from that life, Mark Verber, has an article about Voodoo Sysadmin (among other things) if you want to learn more.)
This frequently takes the form of "it's acting up" -- "reboot it, and try again". Sometimes, this solves the problem, at least temporarily. A lot of other times, it doesn't solve the problem, but it doesn't do any real harm. Put those two together, and you get a classic recipe for superstition: accidental reinforcement (more on wikipedia, or in Karen Pryor's book, Don't Shoot the Dog). That is to say, because it works some of the time, you're bound to try it almost all the time, just in case it works. Often, this is mostly harmless, if perhaps wasteful of time. Sometimes, it creates real harm. For example, rebooting a UNIX system that's having problems because some critical file got corrupted may leave you with no way to log back in and fix it, without getting out installation media. Or worse, it may remove the temporary copy of the still-working version of the file that was lying around until the reboot process cleaned it up.
I fear, though, that I'm getting overly geeky for a point that's more universal, so let's instead go to a real-life example from my very recent past.
I was having a problem with my iPhone syncing its photos to my Mac. Image Capture was saying "No camera or scanner connected." iPhoto simply didn't have a "Devices" section under which it would show up (until and unless I connected another digital camera, which would show up fine). Aperture 3 wasn't showing it either, though it had had partial success earlier (and Image capture used to work). After a long conversation with Apple (and paying the roughly $75 for AppleCare protection on my Iphone, since I was beyond the original 90 days of phone support -- I'd started the call as a Mac call, which was still under warranty), a Senior iPhone Advisor named Kurt told me that there was a known issue wherein sometimes certain images that were downloaded from online, or from e-mail, or maybe even saved from apps on the phone other than the Camera app, would somehow get corrupted (or at least some meta-data about them would), and this corruption would cause a situation wherein the various photo-related apps on MacOS X would simply fail to see the phone as a device with images on it. This was totally what I was experiencing. They're working on a long-term fix for this, and in the mean time the workaround given to me was: Email myself any images not created by the Camera application (screenshots, downloaded images, etc.), and then delete those images from the phone. Note that this does not involve doing a hard reset on the phone, or rebooting my mac, or, and here's the kicker, resetting all settings on the phone, which is exactly what a previous associate had asked me to do (and all the other things were asked, too).
Resetting all settings did not help. It did, however, cause me some general annoyance at having to restore things like my ring tone of choice, and enabling caps lock, and that sort of thing. And to re-enter wifi passwords (I'm glad I knew off-hand the main one of those that I care about; I'll have to go and find the others again, as they become relevant). But that's not what really got me. It also deleted all of my alarms from the Clock application. Uhm, I rely on those to remind me to take some medications each day. And others to make it to regular appointments. I noticed this a couple hours after I was supposed to have taken a dose of medication that I take daily. Now, I take it daily, and being a couple hours late isn't a big deal for the medication in question. But what if it had been something I had to take on a very regular schedule? Or what if I hadn't noticed that the alarm hadn't gone off, and I just missed it today completely? Or missed the appointment that I have later in the day today? Who's to say what would have happened. I'll say, though, that it could have been bad news, if not for me than for someone else who didn't realize they'd lost their alarms.
So, step one was to complain to Apple about this, and ask them to make sure that their associates are all trained to make sure they let a user know that their alarms will go away. Had I known that, I could have made a list of them first, before resetting all settings. I've called Apple, and spoken to another Senior Advisor, and he seemed to take it all fairly seriously, so I have hopes that good things will happen there. Better yet would be to have the UI for resetting settings actually tell you this -- or maybe even be able to turn on and off which settings get reset. This, too, has been suggested to Apple.
What would really make me happy, though, is for them not to have asked me to do something that was totally unnecessary! Resetting my settings didn't help, and I'm sure that while the guy I was speaking to suspected that it might have, the reality of the situation was that he didn't understand why my phone wasn't being recognized, and thus didn't know if it would fix it or not. Maybe he knew he didn't know, maybe he thought he knew and was wrong. Either way, the fact is the same: he didn't know, and so he went with a superstition-based or "voodoo sysadmin" approach to fixing the problem. He even claims he resets all settings on his own iPhone every week, as a matter of course. If that's not superstition, I don't know what is. If I did that, it would drive me nuts... I have a lot of settings changed. And a lot of alarms -- the important ones of which I think are all back, though I know I had others in there that I'll have to re-create from scratch (ones that were off because they weren't set to repeat, but which I would occasionally turn on for certain things -- now, I'll have to actually re-create them when those situations arise again, instead of just turning them on. I can live with that.
But here's the thing:
If there was a concerted effort within the Tech Support industry to try to eliminate all superstitious practices from their support calls, this kind of thing simply wouldn't happen. And I believe it shouldn't have had to happen. Because, as this blog is all about, I believe there is a better way.
"Eliminate all superstitious practices? Shyeah, right." I know, I know, it'll never happen. See Verber's article (linked above): superstition is part of Human Nature. True. I have no argument there. Still, it's the effort to eliminate them that would bring about the change that I want. As I see it, there would be several main components to such an effort:
Educate tech support personnel on what superstition is, how to recognize it, and how to avoid being trapped into it.
Teach these same folks alternative ways of doing things so that they can actually find actions to suggest that will be known to be helpful. Now, this will be impossible in some cases, because they just won't have a way of figuring out what's wrong, which brings me to item #3:
Have software (and hardware) developers provide better instrumentation in their products, and analysis tools which can either be used by support staff, or given to end users to run on behalf of the support staff, with results being given back to them in the latter case. Also involved in this is more and better error reporting, and/or more use of any extant error reporting by support staff. Many of these tools could be built in to applications. Others would be separate tools. Either way, more troubleshooting would be helpful.
If Image Capture had given me some sort of message saying "iPhone detected, but the image database looks to be corrupt", or if there'd been a menu option for "Detailed device detection", or a help item for "Why doesn't my device show up?" with instructions on how to run some debug information, or something, I would have kept my alarms, had a lower degree of frustration, and possibly even saved both Apple and myself some money, by not having had to buy AppleCare (yes, I get it, that *makes* them money), and not having them have to take the call (this is where they get it back -- I was on the phone with them for a while, bouncing between different people, and calling back the next day to let them know of the problem I had with the service I'd gotten -- that may or may not add up to the cost of the plan, but I bet it came close, at least).
And so...
In summary:
Software developers:
Instrument your code, and provide tools for analyzing problems as they're going on. (Example of a fairly decent (if under-technical for the hard cases) version of this: The network connection assistant in Apple's network preferences on MacOS X. It goes through each stage of trying to get online, and tries different things, giving you things to try along any stage that's showing difficulty.
Hardware developers:
Uhh, I dunno. I'm not a hardware guy. But something like the above. And make sure you work with the software folks to build the tools to make use of the instrumentation you're providing.
Tech support managers:
Train your people on the perils of superstitious support behaviors, and reinforce them when they go through the admittedly often-more-difficult process of actually trying to figure out what's wrong. (Oh yeah, and this probably means training them how to do that, too, and rewarding them for doing it, and costing you lots of money in more advanced employees. I bet you it's worth it in the long run, though -- actually fixing the problem without negative side effects makes for happier customers, less likely to call back again about the same problem, and more likely to exhibit loyalty to your brand. But that's just speculation on my part.)
Thank you for reading. I hope this is somehow helpful to someone -- even if only for having listed the workaround to the iPhone connectivity problem, so the next person hitting it can fix it themselves, and save themselves a bit of heartache.
Wishing for a better world,
David
P.S. Oh yeah, and the medical industry could probably do a lot of this, as well. But that's another rant, for another day. See Karen Pryor's book for a brief discussion of this point, when she's introducing the idea of superstitious behaviors.
This post was written on 2010-02-05 (That's February 5th, 2010 for those not familiar with ISO 8601 -- and please, make yourself familiar with it, and use it -- but that's another post), at around 14:31h Seattle local time.
I expect that date to appear above the title of this post, and the final time of me publishing it to appear down below. Automatically, and in a fairly easy-to-find way.
It would be great if all web articles did this. Now, I'll grant you: I've been guilty in the past of occasionally omitting this detail in some web articles of mine, and there are some that need to be corrected to include it. By and large, though, those articles have not been of a news variety, and tended to include only information that I generally considered to be relatively timeless (though really, anything can change, so a datestamp is really still quite desirable). Recently I was reading a news-style article, though, that referred to something having happened "last week". Well, I came across this article from a source other than the front page of a news site. As such, I had no implicit idea if I was looking at an article from today, last week, or several years ago. I was still on the top screen-page of information, in the second paragraph of the article, so I glanced up above, looking for a date, to try to get my bearings. Nothing. I then proceeded to scroll to the bottom, to look for a date. I couldn't find one. I did eventually find one in the meta tags on the page. 2009-12-11. OK, so about 2 months ago.
Surely it would be better to have this information written plainly at the top of the article (ideal), and/or at the bottom of the article (less ideal if "or", more ideal if "and"). That way, (a) readers who have no idea how to look for a meta tag would still be able to find the information, and (b) readers (like me) who do know how to do that will be able, instead, to just glance up while still mid-sentence and grab a context for what they're reading, and continue without having to be interrupted to write a blog post about how frustrating it is that there wasn't a date. :-)
So, please, news purveyors, bloggers, and really any content creators, please: provide datestamps, at least, and preferably also timestamps (sometimes that matters -- especially on the day the item was published) on your articles.
I will endeavor to make sure that all of my future content is done this way, too, and perhaps retroactively add it to some of my old content.
Thanks.
(2010-02-05, 14:43h local)
P.S. (2010-02-05 15:02 local) -- I just e-mailed the webmaster of the site in question. Hopefully they'll fix their site. Yay, reporting problems, so that people might actually have a chance to realize their error and fix them. Though again, that's probably another post.
I will not go into great detail, here, though perhaps requests in comments would get me to say more. For now, though, the short version:
I have come to hold firmly the opinion that Mail Transfer Agents (MTAs) and Mail User Agents (MUAs) should talk more.
For example, it should be possible for me, from my MUA (currently mutt, though I'm thinking of switching to something emacs-based) to flag a particular message as spam in a way that permanently blocks all messages to the recipient that that mail was destined for. Now, obviously (I hope) this only is relevant in cases where one is using a wildcard accept type of rule, i.e. where any username at the domainname in question will get delivered to one particular actual user's mailbox (with perhaps some exceptions going to different users, or, as implied here, being rejected as spam).
Now, perhaps folks just aren't doing this very much any more, and I should get over the idea that all MTAs everywhere should have this capability.
For what it's worth, I wish at least Gmail for domains would do it... and have something procmail-like, too... or rather, something more elaborate than the current filtering rules, which I find limiting. Though, perhaps I'll give it a go, we'll see.
(I'm currently in the market for a new mail infrastructure.)
I'm me. If you know me, you know me. If you don't... well, you'll just have to get to, I guess. If you need help, check out my Photography site, Flickr Stream, blogger profile, etc.
Posts
