Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: support

  • How to Support Plugins

    How to Support Plugins

    This is not meant to be a perfect, will work for everyone, solution. But if you’ve made your first plugin and you’ve no idea how to support it, this is for you!

    I’m going to present this under the assumption that you already understand how to code, even if your coding is about as good as my French. I’m also going to assume that you are a thinking being with the ability to be rational and accept defeat.

    Goliath National Bank - Not a real bank History first. I picked up WordPress back when MovableType decided to change their licenses, and I’ve never looked back. First it was just my blog, then I learned all the cool things I could do to it. The turning point for me was when I decided to rebuild my fansite using WordPress. While I do write code for my day job at a very large bank, I spend an awful lot of time troubleshooting for developers.

    Some very smart people I know!In a nutshell, I take phone calls (and emails) from very smart, very technical savvy people, asking me questions about things I know nothing about and make them work. I support software I don’t use, I support software I don’t understand, and I support software that’s almost as old as I am. It’s a very weird job, but I like it, and I do well at it, which is why I keep my day job and just play with WordPress! And what do I do with WordPress?

    I help in the support forums!
    There's a theme here...

    My job made me accustomed to taking weird questions from smart people about a brand new topic, learning what I need to in order to solve the problem, and hand them the information quickly and in an understandable way. My mom loves this, and knows she can call me about anything computer related, and I’ll find the answer for her. When I started helping on the WordPress forums, this was suddenly a skill whose worth could not be measured. I wasn’t afraid to jump in and help out on topics I was unfamiliar with because I knew I could figure it out.

    Mark Twain knows the secret to success The magic to it, the secret to my power, is that I know how to learn, when to ask for help, and to admit when I don’t know.

    That’s pretty much it. And I’m going to teach you how to do it too, provided you’re willing to think, and to admit that you’re wrong sometimes. Don’t worry, I’ll be wrong right along with you!

    You are not the only user of your plugin, so be available

    Most people who write a plugin do it for a few reasons:

    Andrew Nacin - WordPress maniac
    They need to do something special
    Someone else needs something special
    They want to feel important and praised
    They’re a bored genius maniac (see pic on the right)

    It all boils down to the idea that we do it for ourselves. There’s nothing wrong with that. Remember, as long as that plugin is just yours, sitting on your server, you could do whatever you wanted. The moment you start handing out your cool ‘just for me’ code to other people, there is a level of responsibility that you have to own up to. You’re now a developer and that means you need to help people. If your plugin is up on the WordPress repository, you are no longer making this for you, but for anyone who needs it. They’re going to ask for help, they’re going to tell you that you did it all wrong, and they’re going to be unreasonable.

    Read Me - NOT an option If you’re making a plugin that you don’t want to support, this better be painfully clear on the plugin readme.txt, or you will be in running for my asshat of the year award. There’s nothing wrong with making a plugin and abandoning it, but there is something wrong with not telling people that. For the rest of us who are supporting our plugins, make sure it’s clear how they should contact you.

    The default expectation is that if I post in the forums and tag my topic with your plugin flag, you will see it and reply. There is no law that says this must be the case, but since it is the common way plugins are handled, you must be explicitly clear to people that you want to use a different method. As a forum helper, when I see someone ask for help on a plugin, I always go look at the plugin readme first. If it says ‘for support, go to…’ I always tell people to do that.

    RSS feeds are helpfulNow that said, you still need to remember to add the RSS feed to your reader, because some people don’t read, and sometimes they’ll let you know of something huge in the forums, and not contact you correctly. I’m not saying you need to reply to them, but think of it as a CYA manuver. There’s a great URL that anyone can use for all your plugins: http://wordpress.org/support/view/plugin-committer/YOURHANDLE

    That will update every time anyone posts about any of your plugins. If you need it to email you instead of RSS, I suggest using RSS2Email, FeedBurner or any other web-app that turns feeds into email to alert yourself.

    It’s your plugin

    At the same time, this is your plugin. You designed it to fill a certain void and damn it, if you don’t want it to have dancing monkeys, then you don’t need to! This has been where I see most developers get into ‘fights’ online. People often have unrealistic expectations for free products, and most of why I charge people for phone/email support is because it gets rid of the stupid requests and keeps me sane. If I answered every email, IM or forum post someone addressed to me with the same attentiveness and response-time I give at my day job, I’d be working 60 hours a week on a free product, with no monetary kick back. I don’t have the time for that. Neither do most people.

    When you say no, don't feel guilty The hardest lesson to learn is how to walk away when you feel responsible for your product. Even though these are your users, and these people rely on you, there is a point at which you cannot explain ‘why’ sufficiently for them to understand it. Either they’re stuck in their world, or you in yours, but regardless, you are at an impasse. And this is when you have to walk away. Tell them ‘I’m sorry, but I’m not going to do that. You’re welcome to fork the plugin if you want.’ And walk. Away. Sometimes things are just outside your scope, and if you don’t want to support the addition, you don’t have to. Don’t let people bully you into things.

    The expectations of ‘free’ plugins are crazy, and we all know that. It’s like not feeding the trolls, though. When people are unrealistic to you, you’re under no obligation to support them. But also, when things are outside the scope of your plugin, you can tell them that and be done. I’ve said no to people who wanted things added in, even after I spent a day down the rabbit hole applying code to implement their feature, because I neither wanted to support it nor did I find it useful. At the end of the day, it’s my plugin. I decide what it should do.

    Don’t forget you have a life!

    Most problems people have with plugins are literacy problems. That is they did not RTFM, or they didn’t pass reading comprehension and are over-thinking a problem. I spent 4 hours once at work talking to a woman who didn’t understand what I meant when I said ‘If the folder’s not there, just make it.’ She was certain I was omitting a crucial step, or secret hand shake. This goes back to what I said about why I have a per-hour price for personal support. I don’t have time to walk someone through the basics of how to FTP or edit a file. That’s not the support you need to offer for plugins, and if someone can’t do it, it’s okay to tell them that they need to hire someone. You have a life! Don’t let them take all your free time.

    Otto likes BBQs I have other hobbies besides WordPress. I write, I play guitar, I ride my bicycle, I’m in the SCA, I do some volunteer work for bicycling, I’m part of a couple fandoms, and so on and so forth. I have a family and friends and interests outside slaving away at a computer all day and night for no compensation. So I try to balance my time and yes, that means sometimes I walk away from a coding frenzy, but sometimes you just have to. There are commitments in life, and you will have to sacrifice them sometimes. Don’t sacrifice your self, though. Embrace your life and don’t let one obsession rule it. That will help you keep it all in perspective.

    Users are people too

    Maintaining a plugin will involve sacrifice. The first thing you’re going to lose is free time, but the second is you will lose face. You’re going to get into a fight with someone on the forums, no matter how well you mean. Part of this is because text is an imperfect medium. My father complains about it, because he says it’s not a discussion, but a debate, and most people in the US never took a debate class.

    RTFM or die It’s really hard to remember to be polite, especially when these people aren’t reading the damned manuals/readme/directions. I fail at it often enough that I used to joke it’s why I’d never be promoted at work or made a forum moderator for WordPress. Ironically enough, both those things happened roughly within weeks of each other. I suspect the reason is that while I do lose my cool sometimes and write angry, I mean well and try hard to be polite and do good.

    Every time I train new people in how to work our tech support, I tell them that from Thanksgiving to New Years, our busiest time of year, everyone will make at least one, massive, giant, phenomenal “Oh dear GOD am I about to be fired!?” magnitude of an error. Without fail, at least one person will promise they won’t, and I write their name on my white-board with the date. Without fail they will make a huge error. The point is that everyone makes mistakes, everyone forgets how to reset a password, everyone forgets something basic, even you. So just remember that.

    It’s okay to not know

    Uncle Sam's youngest son, Citizen Know Nothing. I don’t know how set up domain mapping. I have to read the documentation every time, and often I ask Andrea or Ron. On the flip side, Andrea has remarked more than once that when she sees a weird .htaccess request, she defers to me. I know what I know, I know what I don’t, and I have no shame in telling someone “You know, I don’t use IIS and I really have no idea how to help you here.” If you don’t know how to do something, say so. Maybe the person you’re trying to help actually does know how to code it, or maybe someone reading it will know.

    When you make a BIG change, document the hell out of it

    Recently, W3 Total Cache pushed a new version with a lot of cool features and better tools. The problem was that many people found it broke their site. The fix was really easy. Change the new ‘default’ setting for Minify from ‘Auto’ to ‘Manual’ and set it all up manually. The problem was that the developer didn’t make this clear in an easy to find way. He tweeted about it, certainly, but he didn’t announce anywhere easily (logically) located about this.

    Not a vicious circle, but you get the ideaNow W3TC also fails on one of my critical hallmarks of support: Nowhere in the readme (or on the official WordPress repository page) does he say how to get help. I happen to know that if you want to report a bug, you go to http://yourdomain.com/wp-admin/admin.php?page=w3tc_support and use the form there. He also doesn’t link to his website, or even the plugin page on his website from the repository, nor does he mention that he doesn’t help you configure the site for free.

    While I love this program and use it on all my sites but one (at 60 hits a day, it doesn’t need it), I think he’s wrong to not spell out how support works, and he failed to explain what was happening. All we know is he fixed this:

    Fixed bug with existing installation upgrades: set minify to manual mode by default

    Nothing was clearly documented, nothing was clearly explained, and no one really knew where to go for help, which meant the forums were filled with a lot of angry, ignorant, people, getting no responses from the developer. Simply put, it looks bad, and if people feel that the support is non-existent, they’re going to get angrier, and post things like how you suck and they’re leaving your product, which makes you angry and feel bad, and less inclined to help them at all, the ingrates! It’s a vicious circle, and spirals downhill really fast and segues right into my final point…

    They’re not attacking you

    Take a deep breath. What I just said about W3TC can very easily sound like an attack. A lot of the time, people will argue they’re not attacking, they’re being passionate, and in the same breath accuse you of being overly defensive. You’re going to, rightly, be defensive and proprietary of your plugin because, as we discussed, it’s yours. You put in the sweat equity, you researched, studied and tested, and you made something awesome. It hurts when people tell you it sucks.

    Alas, they’ve forgotten you’re a person too. There isn’t a good/easy way to remind them you should be treated as a human, sadly, so when people start getting fired up and telling you that you suck and the plugin sucks, the best you can do is be the better person. I mentioned before that users are people. This is not a repetition of that fact, but a reminder to yourself that there are days where all this is going to be terrible, awful and you feel like the users have pitchforks and want your head

    When this happens, they’re not attacking you. They don’t hate you, they just don’t know how to explain problems without hurting you, because you’re always going to be too close to the problem. I’m willing to bet Bill Gates and Steve Jobs still feel twinges of pain when people rant about their products. Like a parent, you love what you’ve created, and every slight against it feels like fishhooks in your skin. This cannot be avoided, and the best you can do is recognize that they are a little unreasonable, and that your reply is probably a little unreasonable, and stop.

    If you can’t address the situation without feeling your skin heat up or your blood pressure rise, walk away for a while. We’ll still be here.

    In Summary

    I would never say ‘don’t sweat the small stuff, and it’s all small stuff’ or anything trite like that. I will say the point of all this is to be honest, be upfront, be clear and keep it all in perspective. That way you will have both respect and your sanity.

  • Common IT Answers

    I actually have this sitting on my desk at work. It’s so old that the fluid has evaporated enough that it doesn’t work right anymore. But I keep it and use it. What is it? A magic 8-ball of tech support! Many moons ago, our CDW Vendor gave my boss a Magic 8-Ball for programmers showing the answer “IT’S NOT A BUG – IT’S A FEATURE”. The top of the ball says “For your most commonly asked IT requests.” Some of the answers are blatant CDW adverts, but the rest are answers I know I’ve used at least once:

    • Did you press the right button?
    • I can’t test everything
    • It worked yesterday
    • It works like I programmed it
    • It works on my machine
    • It’ll be fixed in the next release
    • It’s a Beta – What did you expect?
    • It’s an unlikely coincidence
    • It’s just an isolated incident
    • it’s not a bug, it’s a feature
    • It’s not supposed to do that
    • Please submit a formal request
    • Plug it in
    • Program works. Must be user error
    • Reboot
    • Someone changed my code.

    Sadly, the thing is dying. I may have to learn how to make a new one, since right now it’s stuck showing me a corner instead of a face.

    I’m not the only person who uses these, though. Eric Mack did as of 2004!

  • Don’t Fear Wandering Off Topic

    Don’t Fear Wandering Off Topic

    Sometimes when you’re debugging, you haven’t the foggiest idea how someone managed to screw something up so badly that they got this particular error. Naturally they’ll tell you that they didn’t do or change anything, and sometimes they’ll even be telling you the truth! It’s at that point I try to teach my guys that it’s okay to wander off the script and start talking about anything else, in order to learn how the person thinks.

    Everyone’s thought process is different. Some of us learn by reading, some by watching, some by doing, and others by listening. There’s no one perfect way to solve a problem, but that doesn’t stop managers from trying to codify the how-tos into a script to follow. We’ve all been there, where we’re told to reboot our PC to solve a modem problem. There is no secret shibboleet call to get you to the smarter people.

    I will say that the reason the scripts exist is because they do work. I couldn’t begin to tell you how many help tickets are solved when I ask ‘Are you using the default password of changeme?’ Heck, even telling people ‘Reboot.’ is correct sometimes. That’s the thing, though. SOMETIMES. You have to learn how to tell when ‘sometimes’ is now and when it’s not. For example. I add a user to a domain group on Windows. Our setup of Windows XP systems pull down domain group info (and all permissions allocated therein) on login. User says the permissions that come with the group aren’t working. I tell them ‘Reboot so XP can apply the settings. Sometimes it gets persnickety.’ They reboot, we’re done. But notice, I know how and why the problem occurred, and I can explain it to the user.

    But. Sometimes you get yourself down the rabbit hole with a crazy problem. “Hi! Every time I add a file, it locks the system.” Okay, time to sort out what’s getting locked. What’s not cleaning itself out, what’s acting ‘weird.’ Does it work for you? It does. Interesting. What’s HE doing? Let’s ask. “I’m using a home grown script to add files.” Oh. Betcha that’s it. I actually spent three days and a call to the vendor trying to debug a problem like this because the guy refused to accept that HIS script was POSSIBLY screwing things up. Actually he didn’t even mention the script until I started chatting about workflows and productivity and he mentioned, in passing ‘Yeah, we had to write a script because it took too long.’

    This isn’t about how when you ask for help, be specific and tell them exactly what you’re doing in as clear and simple a way as possible. This is about how, when you’re talking to someone, it’s totally okay to wander off topic and ask something off the wall. “Are you using Firefox beta 4? You are? Did you know that there are problems with that and TinyMCE?” Sure the question sounded hella random, but it was the debugger’s brain pinging off the wall at a memory.

    When you’re helping people, remember that they learn differently from you as well. As much as people tout ‘thinking outside the box’ as a call to innovation, I think that’s not what they mean. What they mean is being willing to take a chance, a risk, and make a stab in the dark at a possible answer. A genius is the one who looks at a moldy cheese sandwich and thinks ‘What the hell is IN that green stuff?’ A genius is the one who says ‘It’d be easier if could clone a server.’ A genius is the one who both thinks and applies the thought to something.

    When you’re stuck troubleshooting, wander off topic. Be willing to think of the crazy things and voice them aloud. Be willing to say ‘I doubt this has anything to do with it, but what happens if you do this…’ Be willing to ask the ‘stupid’ questions. Go ahead and talk about Bad Wiener day. The scrunchy joke may make you remember something totally off the wall.

  • Basic Troubleshooting Is Still a Must-Have Skill

    Basic Troubleshooting Is Still a Must-Have Skill

    How low is too low?

    I wish I could say that lately I’ve noticed people asking ‘dumber’ questions on support forums, and while I do firmly believe the world’s IQ drops significantly between Thanksgiving and New Years, that’s not the problem here. People aren’t getting dumber. The problem is that the better people get at making software, the lower the technical requirement becomes.

    Look at email. Back when it was elm or pine, you had to really know what you were doing to get in and send mails. Then we got a couple GUIs, and you could keep all your emails on a floppy disk (which we all had a million of, thanks to AOL), carrying them around from computer to computer, Mac or PC. Everything to do with computers has this curve: First only the hard core programmers can do anything. Then the tech-savvy users, who are usually friends of programmers, get in on it. Then the smart kids who play with stuff. Then their family. Then everyone. Then your grandmother.

    By the time your grandmother gets around to things, it’s easy to use, easy to understand and friendly. This is, inherently, a good thing! To make the transition from geek toy to something usable that will change the world, you must make the entry barrier low enough for anyone with a reasonable amount of brain-power to use it. Twitter’s a great example of this. It’s easy to sign up, easy to use, easy to understand. Like anything else, you can get overwhelmed by the data influx, but that’s true of all technology. The telephone, for example, suddenly brought in the ability to have your dinner interrupted. It brought change where everyone has a phone. Of course, now we all have cell phones, but the idea remains the same.

    So when I look at support forums and people are having trouble installing software on servers via FTP, I put my head in my hands. Sometimes this stuff is supposed to be hard. We can all use phones, but we can’t all fix phones or even build them. And that’s okay! We all have skills. Twitter would probably be something hellish to install on your own website, but to utilize their site? Not so bad! And again, that’s okay.

    If you want to host your own website, you’re going to have accept this fact: You will need to be a smart, technical savvy, person.

    There. I said it. Yes, you can totally be too uneducated to run a website. Here, I’ll go all the way! You CAN be too dumb for WordPress!

    But let me stress this one more time: IT’S TOTALLY OKAY TO BE TOO STUPID TO RUN YOUR OWN WEBSITE!

    See, people get hung up on this. They forget that there’s a huge difference between running a website and posting news to your site. The line between a webmaster and a blogger is blurry for a reason, and that’s what’s causing all these headaches. Back in the day, if you wanted to run your own site, you had to be a webmaster. Now? Not so much.

    A webmaster is generally someone who thinks ‘Oh, sure, FTP, SSH, and SQL, no problem.’ They may prefer something like phpMyAdmin versus command like mySQL calls, but the most important thing is that they’re comfortable troubleshooting. A webmaster is the person who looks at an error, immediately looks it up (if they don’t know it off the top of their head), goes to forums, skims posts, reads what others have tried, and is willing and able to try things like a reverse DNS check. A webmaster makes backups so, at worst, they’ve only lost a day of work.

    A blogger is a writer. A creator. Someone who can make content. A blogger looks at a sunset and creates a haiku. A blogger takes a photo of a naked man on a bicycle. A blogger tells you the drama of returning an unwanted present, or about how her son wants to wear a dress on Halloween.

    And still, every day, I see people who don’t understand .htaccess asking for help with errors on their websites. I see people who complain they can’t auto-update their site from the inside, because FTP is too hard. I see people complain the magic 5-minute WordPress install is too hard. And I think that, perhaps, we’ve lowered the bar too much. If we’re at the point where the non-technical people are complaining it’s too hard to do something that is, by it’s nature, a technical thing, then we have a problem.

    This problem is compounded by webhosts who, in order to make money, want to make it ‘easier’ for you to run a blog, so they have auto-installers. They lower the bar. Then we have web-apps (like WordPress) which let you install, from within the app, plugins and themes. This means that someone could create a site just like this one, without ever touching FTP or SSH. That also means when things go wrong, and they will, you’ve got someone stranded, crying that this ‘easy’ application sucks, you’re terrible, and whyyyyy meeeeee!

    Every single person who’s ever worked support just started nodding their head and reaching for a drink.

    So here’s the deal. Yes, you can become smart enough to run your own website, but before you jump into it, think about how long it took you to get comfortable with your computer. How long was it before you could email, link videos, and save MP3s? Do you know how to make folders in your email app? Do you know that emailing 200megs to someone will piss them off? Did you need a book, or someone to sit by you and teach you all this? Are you comfortable googling errors and applying fixes? More to the point, are you willing to get your hands dirty and make mistakes?

    If you want to run a website community, you may need to break down and hire someone to do the heavy tech lifting for you. Just like you would want to hire someone to create cool art, or decorate your house. Sometimes you just need to grab an expert. Remember you can’t get something for nothing. Either invest the time and money in learning, or in someone who already knows it all and can support it for you.

    Apropos of all of this, Google has a new site called Teach Parents Tech. Lowering the bar. Again.

  • I’m not a coder and I need HELP!

    IT may be for rockstars but really, the trick to getting the best help from your techs is simple. Be honest, think about what the questions we ask you mean, be direct, and explain what you mean. Seriously. That’s all we need. Every time someone says ‘It doesn’t work’ or posts a reply in a forum ‘Me too’, we cry a little. If you’re vague, or don’t use normal terms, we may get a little pedantic on you, but the reason is that we need to make sure you have the problem we’re thinking you have before we tell you how to fix it.

    Be Honest

    The number one reason why something ‘magically’ breaks is because you changed something. This is often seen, from the end-user perspective, as an at-fault change. “I changed this, it broke, therefore it’s my fault.” And in the business world today, no one wants to be at-fault. It’s an ego thing, but it’s also a responsibility thing. Here’s a secret for you. The IT people don’t care whose fault it is. Seriously. We just want to fix the problem and make sure it doesn’t happen again. That’s all we want. So when we ask you ‘Did you make any changes?’ just tell us ‘Yeah, I modified my profile to have this line.’

    Sometimes YOU may not make the change. Sometimes you may have the server or someone else make a change. Sometimes the change seems, to you, totally un-related. It doesn’t matter. Tell us. “I didn’t change anything with IE, but I did install a new twitter app.” That may be the cause! Unrelated software sometimes is written poorly, or weirdly, or just in a way that conflicts with your other software.

    If you’re using a CMS like Drupal, WordPress or Joomla, plugins often break things in insane ways you never predicted. And server upgrades can cause conflicts with older code on your installs. Always pay attention to what’s going on with your server.

    Think about what the question we ask you means

    When we ask you if you changed anything, think about that for a moment. It’s like ‘Did you change your oil?’ That’s a pretty simple yes or no answer. But what does the question ‘What did you change?’ mean. Well pretty much it means ‘What’s changed?’ But it also means ‘What were you TOLD to change and you didn’t change?’

    The other day, I had a weird situation where someone had modified their profile a month ago to have a line to let them do something else. This was seen as inefficient, and the server guy fixed the server and told them ‘Remove any changes you made or things may break.’ They did not. Fast-forward a couple weeks and my monthly process failed. I asked if they changed anything. They said, honestly, they had not. I talked to the server guy who said ‘Well, they SHOULD have changed this…’ We changed it, it worked. Strictly speaking, they were honest, but they didn’t think about the question. They got hung up on that at-fault point. “WE didn’t change anything,” they said in email and I replied ‘Yes, but you actually were told to change that. It’s not a big deal, it’s an easy fix, but next time, remember to make the recommended changes, or at least document why you didn’t make the change. It’ll make it faster for me to debug.’

    That was singing to the wall, though. The guy was let go the next day.

    Be Direct

    This does not mean ‘Be an asshole.’ And in fact, I subscribe to Wil Wheaton’s rule: Don’t be a dick. What it means is don’t beat around the bush. I don’t need to know that you’re logging in from home and it’s distracting. I don’t need you to IM me and ask ‘How are you?’ You don’t care, and neither do I. What we care about is this: What’s the problem?

    I get a lot of IMs at work (which is why I don’t use IM at home, by the way) with people saying ‘Hello! How are you?’ and we waste about 10 minutes ‘chatting’ about stuff no one really cares about. I get that you’re trying to be polite, but you’re calling the help desk. The other problem is when someone says ‘Do you have a minute to help me?’ Honestly, rarely, but since I don’t know what you’re talking about, I can’t tell you if I have the time, so I have to say ‘Depends. What’s the problem?’

    Here’s an example of a poor IM/phone conversation with tech support (this is, by the way, an actual conversation I had recently):
    User: Hi!
    Tech: Hello, this is Jane, how may I help you?
    User: It’s Tom.
    Tech: Hello, Tom. How may I help you?
    User: How are you?
    Tech: Fine, thank you. How may I help you?
    User: Do you have a minute?
    Tech: Depends on the problem. How may I help you?
    User: I’m having a problem.
    Tech: Yes, with what?
    User: With your application.
    Tech: What’s the problem.
    User: It’s not working right.
    Tech: Okay, can you be more specific?
    User: It’s my password.
    Tech: Okay. What, specifically, is wrong with your password?
    User: It doesn’t work.
    Tech: Does it give you an error message?
    User: Oh, yes!
    Tech: And the error says….?
    User: Something about the password being bad.
    Tech: Can you try to login again and read the error, out loud, to me?
    User: Sure. Okay, it says ‘Your password is incorrect and your account has been locked out.’
    Tech: Ah. Okay, I’ll unlock your account and set your password to 123456 – Once you log in, you’ll be asked to change it.
    User: Boy, that took a long time!

    Look at how long that was. Want to see the GOOD version of the same conversation?
    User: Hi, Jane, it’s Bob. I’m having a problem with your Foobar application. When I try to login, it says my password was incorrect and I’m locked out. Can you help me?
    Tech: Sure thing, Bob. I’ll unlock your account and set your password to 123456 – Once you log in, you’ll be asked to change it.
    User: Thanks!

    Look at how much faster that went because Bob was direct and to the point. He got his problem fixed really quickly because he came prepared. And if the Tech had been busy, he could have easily transfered the call, or opened a ticket, or done a variety of things.

    Oh and for the record, I answer the phone: Company name, this is MY NAME. How may I help you?

    Explain What You Mean

    In my previous example, Bob got to the point and explained what the error was right away. This falls under ‘Explain what you mean.’ The phrase ‘It’s broken’ has lost all meaning, if it ever had any. And due to the complex nature of computers, even if your problem as simple as a botched password, we really do need you to explain ‘When I try to log in, the software says my password is invalid.’

    If you have a weird error, take a screenshot. They are rarely a bad idea, and can sometimes streamline a problem from ten minutes of talking ‘Okay, where is the icon?’ into a quick ‘Oh! Yeah, I know that one.’ If you get an error message, use the exact error with the exact verbiage, in your support request. Also remember to put your screenshots in a generic format. While PDF, RTF and DOC (and DOCX) are mostly universally readable, XPS is not. PNG is also a great one. Anything that is readable only by proprietary software is a bad idea, even if you know the other person has that software!

    Also be descriptive about what you’ve already done to trouble shoot. Don’t say ‘I did everything I could find online!’ That’s vague. Say things like ‘I tried to reset the admin password via SQL, email, PHP, and the emergency script.’ That’s descriptive and tells us what we can skip! On the other hand, don’t get all pedantic. Likely it doesn’t matter if you logged in from home or from work if your email crashes every time you read an email from Bob. On the other hand, if you can get to a website from home and not work, the odds are location does play a factor. While you should be descriptive, think about relationships between what information you’re providing and what your problem is. Later on, you might be asked ‘Does this work if you try it at home?’ But we probably won’t ask if it works on your Mac, if it’s a Windows Only application. Again, think about the questions and the relationship.

    Don’t get mad when you’re treated like a noob

    If you’re a user, sometimes when you provide a limited amount of information, techs default to the lowest common denominator. If you ask a question which we think is pretty standard, is answered in the FAQs (or by 5 minutes in Google), we tend to assume you’re new at all this, and pitch you the simple answer. This means you DON’T get told how and why something works, just how to do it. This means you may get what looks like a flippant response. This does not mean we, techs, think you’re an idiot. It means we can’t tell, from your post, if you’re a BOFH or a bean counter. So we assume bean counter and if you reply ‘Yeah, I did all that.’ well it’s your own damn fault for not telling us what you did in the first place.

    I try not to treat people like rank newbies, but. But. Sometimes I get a question that is mind-numbingly obvious with ten minutes of looking. Asking for help should be the last resort for some people. Like if you’re running a blog on your own server, you need to learn how to help yourself. On the other hand, at work, you should call for help when the software breaks. Someone is paid to fix it, and you should utilize them. Of course, if the techs have made a quick FAQ ‘if you get this error, you need to delete this temp file’ you should read it and try it.

    How to write a good help request

    So you’ve read all that and you want some examples?

    For your help desk at work, it’s pretty simple:

    I’m using software FOOBAR and when I try to do BAZ I get the following error: . I’ve included a screenshot. I was able to do BAZ yesterday, and I have not installed any new software.

    I’m a new user of FOOBAR and I can login, but when I click on BAZ, nothing displays in my right hand menu pane. Included is a screenshot.

    I need to use FOOBAR. How do I get it installed on my PC?

    Not too hard, eh? At work, generally people know if you’re an end user, a developer, or a programmer, and can skew support thusly. For public support forums, however, we have no idea so here’s a good idea:

    I’ve been using FOOBAR since version 2 and I recently upgraded from 2.9 to 3.0. Now when I try and add a new BAZ, I get an access denied error with the following output. I’ve disabled all my plugins and re-copied the files up. Same problem. I’m using a linux server and I have PHP 4.

    Variations of that rarely go amiss. Also remember on CMS support forums, most of the people there are volunteers, so calling them names will get you shunned, if not banned. On free forums (WordPress, Drupal, etc), you’re NOT a paying customer, so don’t expect to be treated like one.

    Do you have advice for the best ways to handle support requests, as a tech or a user? Sing out in the comments!