More what you’d call “guidelines” than actual rules

Edit: Forgot to link this in the original posting: “Help Vampires: A Spotter’s Guide” by amyhoy (Twitter)

If you have ever interacted with me on IRC, you know I spend a fair amount of time in the WordPress end user support channel, as well as jQuery so far in 2012. During the years I have spent helping others, I have observed a lot of success and failure in helping people solve issues they run into using these tools. Originally this was going to be more of a proper “tutorial”, but thanks to collaborative help from trepmal (Twitter), andrea_r (Twitter), ericmann (Twitter), sabreuse (Twitter), ipstenu (Twitter), idiot_girl (Twitter), DarkArtist69, and StevenCodes, it will come off a bit more like guidelines. I want to thank them all for their contributions and know that the feedback will be quality as many have participated in support for WordPress for a long time, either by way of the forums or the IRC channel.

There are two sides to support. The people providing the support, and the people seeking support. For each side, I have provided two types of guidelines: respecting each other and helping to resolve the issue at hand. While I have used WordPress and jQuery as examples so far, these are meant to be agnostic and should be true for any type of online support. The one point that I am going to put the most emphasis on, for both sides, is this. DO NOT BE AN ASSHOLE.

For the helpers

Respect the user seeking help:

• No matter what the person claims about themselves, be respectful and do not call them a n00b/newb/etc. It is demeaning and does not help.
• Be tolerant of different levels of knowledge and experience. Not everyone is at the same level.
• Avoid using language like “You did this” to the user. It can make them feel like you (the support person) are blaming them for their problem. Also avoid sarcasm as much as you can. Nine times out of ten, it does not translate well in text.
• Apologies can go a long way, such as “I am sorry you are experiencing this issue.” The user wants to know you genuinely want to help them and are willing to help.
• Some people do not ask for support until they are already really frustrated, be sympathetic to the problem and do not assume they are mad at *you*
• Do what you can to assess the person’s experience level. For some, a link to a plug-in is a better answer than a code sample, and vice versa. The right answer for the person beats the “best” answer in abstract terms.
• Do not make things personal. It is not about the person seeking help, their level of expertise, their language skills, or even their tone when asking for help. Stay calm and professional and focus on the question/issue, even if they come across negatively.
• Be patient, as the person you are aiding may be at their wit’s end. If you are unable to be patient or calm with them then just step back and let others help. Also, be patient with typos, misspellings, and “wrong” word choices. Not everyone speaks English as their first language or may be rushed to get their question answered. Communication barriers plus frustration results in many confusing typos.
• Avoid criticizing site design when possible. If you must comment on anything, make it constructive criticism and not “zomg this sucks!”. They may be working on functionality first, then style.

Helping answer questions:

• If someone is unclear with their question, ask for more specific information and try to pinpoint exactly where the issue is occurring.
• Do not be afraid to say “I don’t know”. You should not and can not be expected to know everything.
• Just because you, specifically, can not solve the issue or you feel you are not knowledgeable enough to help, does not mean you can not help direct the person to a solution. Any new information that can help is better than no information.
• If there is a more appropriate channel for help, do not be afraid to suggest it IN ADDITION to where they are now.
• Do not be afraid to ask for pointed out examples, code pastes, or jsfiddles. Also, ask for a URL so that you can look at the HTML source. This can help show various plug-ins in the header, any enabled caching or allow you to look for software/theme version numbers to see if anything is outdated. Firebug an Chrome’s debugging tools can also be used to troubleshoot.
• In relation to browser debugging tools, do not just point to them and say “use this”. The person may not be familiar with the tools at all or how to use them. If you do, provide links that show, at least, the basic features and how to get started.
• If you know someone who has more knowledge regarding the area for the issue, ask if they have a few minutes to help.
• If you are responding to someone with a code sample, be sure to explain what it does, why it does what it does, how to use it, and whether or not you have tested it beforehand.
• Ask the user “What have you tried?” or a variation, to determine what steps they have already done to attempt solving the issue. This can also give you the steps to replicate solving the issue, if needed.
• Provide links to further documentation. Do not assume that they have read the docs or even know where documentation is. Ask “Have you followed these steps at all?” If they have read the documentation, ask at which step things stopped working at.
  • If documentation does not exist, try to find resources or Google results for them, for the time being. If the documentation *should* exist and does not, make a note to write some in the future or to pass it on to whomever is in charge of the documentation of which area is missing.
  • If you provide an external resource, READ through it carefully. Too often support people can buzz through quickly and skip already provided information.
• Do your best to answer the question the person meant to ask, not the one they literally asked. “Is this possible?” should never be answered with, “Yes, it’s possible.” They are asking *how*, just not correctly. If someone asks how to do something that is clearly a case of “doing-it-wrong”, it helps to answer what they asked AND also explain why it is the wrong approach, then explain how to do it right. Do not just “cop out” and answer the question, but also do not smack them with a “you are wrong” answer while leaving them grasping. Educate on proper ways to solve a problem.
• Asking “Can you explain what your overall intent is?” can go a long way as to why they are asking what they are asking, if the question seems off the wall. If you can see their big picture, you may be able to go “oh, here is a better way to do this..”.
• Do not give answers to questions they did not ask. If someone asks for plug-in suggestions for a task, do not tell them that they should build their own solution from scratch, no matter your personal feelings towards other plug-ins that try to solve the same task.
• If the person is willing, help educate “how to fish”. Helping them learn how to research and solve their own questions can go a long way, but is not an end-all-be-all solution all of the time. Some people just do not have the time to research though, and need a more immediate solution. Sometimes talking things out can help “flip the switch” in their mind. This does not only apply to talking things out to remind them of an answer — it is also a model of the kind of thought process that happens in troubleshooting. Talking it through is educational in itself and helps explain why, more so than just getting the solution.
• Sometimes you will have to help calm the person’s fears. Let them know what will happen when they push the button. “This button?” “Yeah that one right there.” “The one I have circled in the screenshot?” “Yes, please click it and that thing you want to happen, will automagically happen, and your site will not blow up. I PROMISE.””

For the person asking for help:

Respect the people providing support:

• Respect the specified topic for the room you are in, and try to stay within its bounds. Off-topic chatter may be directed elsewhere.
• Do not assume that the support people automatically know what you are talking about.
• Realize the support personel are not there to judge how your site appearance, but to help you solve your problem at hand. They should not offer opinions unless requested.
• Support personnel may ask you to go through troubleshooting steps (like disabling certain components). Understand that this is a process to try to isolate the problem, not a suggestion that you can’t/shouldn’t use XYZ widget/plug-in once you are back up and running. However, there may be some cases where it is advised not to use XYZ widget/plug-in. This should be for good reasons, like known security issues or multiple varying issues indicating it is not ready and stable enough for distributed use. It is not intended as an insult to your site or personal taste.
• Be patient. At times there may not be anyone around, or the people who are there may not know an answer to your question. In time, someone with more experience may join and know how to better help. The present time of the week or different time zones can also dictate activity levels. Many people may want a break throughout the weekend and opportunity to socialize with friends and family. Others may not be awake when you are there. If an IRC channel is “dead”, seek out a forum that would provide a more persistent posting that people can read once they get back to their computers.
• Be calm. If you are agitated or aggravated, you risk coming off as so in your typing and may put others off from helping. Take your time when asking questions if you are irritated. There is chance that someone helping you will get just as irritated if you are rushing things.
• Do not make things personal. People are here to help you, so do not take it out on them if you did not clearly articulate your question the first time. Just try rephrasing or offering examples of what you mean. Once you start taking personal shots, the person may not wish to continue helping. You also risk alerting the support moderators who may ask you to take a brief break and return later when things have cooled down. If this persists multiple times, you may lose your ability to use the resource temporarily. If issues still persist, it could become permanent.
• Using CAPS LOCK, exessive!!! exclamation!! marks!! and OMG WTF BBQ ELEVENTY!!! may delay receiving help, as behavior like that is perceived as immature. Insisting that “It’s for a client” or “I’m on a deadline” will not likely prioritize your questions as “high importance”. Everyone’s questions are of equal importance, but other users may be kind enough to let you receive attentive help first.
• Many times people in support channels are helping for free and on their own time. Do not assume that the person helping has a specified amount of time available to help you work through your problem from start to finish.
• Try to respect the primary speaking language that the support channel uses and proofread, the best you can, what you are posting before you post it. Sending “I need hleps with teh ting n my page” is going to hinder the speed at which you get help at.

Help them help you:

• Brief answers can be construed as terse. Sometimes you will have to explain more. Smilies go a long way when displaying your emotion to the user, if you are happy about how the problem is getting solved more or less the helper will be excited for you and help you solve the problem fully.
• Provide links to your website in question, if possible. Local development is more difficult to help with, but is not impossible. You will need to provide a lot more examples and pastes since only you can actually see the website. Support personnel will often look at various aspects of your website, in order to determine different factors and to eliminate a lot of back and forth questions. Screenshots can help with describing visual issues and can provide SOME help for CSS related issues in regards to different browsers.
• Be willing to try things. The reason you are asking, is because you are putting trust in the support help having more experience.
• Explain what you have already tried on your own, what resources you have found, and what happened with what you have tried. Merely asking for help leads to a lot of “let me Google that for you” sentiment from observers. Some people will do a search for you because they know of somewhere that the same issue has been discussed and solved already. If they provide you with that, and it still fails, let them know and seek more guidance.
• Follow up with found solutions, especially if asking on a forum ( Wisdom of the Ancients XKCD Comic. This will help future searchers who have the same issue. ). Drive-by “I need help with X” questions just irritate support types. Coming back to explain “OK, that worked” or “That did not work, but I am moving on” provide at least some closure for those dedicating their time to helping you. If you found a completely different solution that worked, show how you solved it.

Hopefully using what is above, as well as anything not listed, you can aid in many pleasant support channel experiences for anyone you encounter, whether you are helping or receiving help.

On the heels of President Obama coming out in support of equal rights for same-sex marriage, pun intended, I must confess a growing <3 for SAM. SAM is the Sioux Area Metro, our local public transport.

I am regularly looking for ways to reduce my expenses and lead a more frugal life. So far, I’ve focused mostly on transportation expenses, especially with how gas prices regularly are. 2012 brought in myself having a membership at Meso, and with this membership, need to travel from my apartment at the southwest corner of town, to downtown Sioux Falls. Between the mentioned gas prices as well as parking fees, I knew that this was an opportune moment to cut down on my reliance on my car, and thus costs associated with traveling downtown many times a week.

Enter SAM into the picture. Bus stops couldn’t be better located. The Southwest Center stop for the bus system is approximately half a mile from my apartment complex, and the downtown bus stop is within a block of Meso. Perfect for my needs! Last thing I need to make this situation highly cost effective is a 30 day adult pass, which costs a mere $25 for unlimited use. This prevents me from having to add wear-n-tear on my vehicle and spares me from filling up my tank regularly. I still drive some places, but it is needed less and less. Driving can become dedicated more to special occasions instead of heading to work.

One of the side perks with using SAM is the fact that I’m forced to walk a little bit. I’m a web developer, I don’t succeed the best with exercise and physical activity. I’ve always found that doing things that force me to walk succeed a lot better than me trying to force myself to a gym.

All in all, I’m taking advantage of a situation that allows me to get out a bit for very low cost and many benefits, some that aren’t even mentioned in this post. If your local public transport offers convenience for you in your routine, I encourage you to try it out and see how it goes. Maybe you’ll fall for your local “SAM”, no matter the acronym.

Despite having a rundown of each day’s activities in an evernote note, I am going to get this blog post written and published before I forget any details. This may be a long post, be warned.

Introduction

As some of you may know, I was recently invited to an in-person documentation sprint with Mozilla, in their California offices. We would be spending three days together working on Mozilla Developer Network (MDN), editing, revising, and creating documentation, demos, and examples for modern web technologies. For those of you who don’t know, MDN is Mozilla’s central location for documenting all of their projects as well as as much possible about the open web. I was thrilled to be invited, but was naturally hesitant because I was not sure how I would afford to make such a trip. However, Mozilla said that they were going to cover the costs of air travel, accomodations, and hotel. Once I realized that all of that was going to be taken care of, there was little that would manage to make me say no, and after confering with my parents, I happily accepted the invite, and started preparing for the trip.

I do not get to travel very much, and when I do, it’s usually not very far, so while I would be working on “web nerd” stuff majority of the time there, I always considered this to be a vacation for myself, in a state that I had never been to. As an added bonus, my good friend and sometimes work partner Amy Crook lived in the area and I knew I’d have the chance to meet her as well. I flew out from Sioux Falls in the early afternoon of Thursday, April 26th, and arrived in San Francisco around 4pm-4:30pm Pacific Standard time. This allowed me enough time to get to the hotel that I’d be staying at, get checked and settled in, and meet up with Amy at the Ferry Building in San Francisco. This building was within a block of the hotel, meaning I was very close to the San Francisco Bay for the duration of my visit. However, I did run into some small stumbling blocks in that my debit card was not liked by the hotel’s system, and I was not going to be able to use it anywhere inside the hotel. This proved to not be an issue at all as I avoided any charges the whole time, and I was able to get some money out of the ATM, just in case I needed some. After a wonderful meal and talk time with Amy, we parted and I spent the rest of the night in the hotel, waiting to hear of official plans for the next day. I didn’t want to go wandering around quite yet because I had just gotten there and knew no one. Finally Friday’s agenda showed up via email.

Friday

Friday’s agenda had us spending time in Mozilla’s main office, located in Mountain View California. In order to get there in time to put in a good hard day’s work, we needed to leave by about 7:15am. It was at this time that I started meeting everyone I’d be spending the weekend with, and getting to know them initially. We had a group of about 10 people, from as close as Los Angeles, and as far away as Bremen Germany. From here, we all proceeded towards the local subway station and made our way south. Once we reached the end of the subway system, we transferred to Caltrain to make the rest of the trip into Mountain View. Once we arrived, we had an initial discussion about what each of us wanted to work on and quick brainstorming for topics that people could choose from.

Firefox logo on the Mozilla Mountain View office wall

This first day was a slow start for me, and I didn’t do any hugely significant contributions, but did stick to minor edits and rewrites to help make topics more clear for others. Lunch was eventually delivered and we all enjoyed some sandwiches by a local business, and was a nice break. Otherwise, beverages and snacks were available in the kitchen areas of the office. Towards the end of the day, I noticed a note in the collaborative etherpad holding the group’s notes, that there was a request for some work to be done on the “Firefox for Devs” section, and some help with docs relating to the new developer tools that are being built into Firefox. Since this is one area I have interest in, I noted that I would work on it more on Saturday. After we were done working for the day, we headed to The Cantankerous Fish for dinner. I am not a seafood fan by any means, but I was not going to make myself the sore thumb of the group, and made do with a Roasted Beet Salad. After dinner, we reversed our path and made our way back to San Francisco. If we all learned anything on our official first day, it’s to make sure that when passing out train tickets, you don’t pass out the receipt as a ticket, and leave the actual ticket behind. Thankfully the crew on the train were kind enough to not kick one of our group members off, and we were able to finish the trip. Finally we got back to the hotel and said our goodnights after working out when we were meeting the next morning. I wasn’t quite ready to retire to my room quite yet, and decided to spend an hour or so wandering around the immediate area and made it my mission to find my way to the San Francisco office a night early. I made a couple incorrect turns, but thanks to GPS, I was able to get back on the right path, and found the location before returning to the hotel for the night.

Saturday

Since we were staying in town on Saturday, we were able to sleep a bit more, and agreed to meet in the lobby around 8:30am before making our way to Mozilla’s San Francisco office. This day was much more productive for me, as I created and wrote up a lot of documentation on creating and managing Firefox profiles for various reasons including testing out Firefox’s multiple development channels. I also managed to get other quick edits in, much like I did on Friday. The work portion of the day was very much like Friday’s, and lunch was once again provided by a local company. To end the work day, we had a brief presentation showing accessability technology used on the MDN website. This proved to be surprisingly useful as together we discovered that a hidden area at the top of the page was the first thing that the tab key went to. This is not optimal for someone who is blind, and I’m sure a bug was filed. Due to our evening plans, the work day was scheduled to end an hour and a half earlier. These plans included a ferry ride up to Sausalito for dinner. This was a very exciting chance for me as I knew we would be riding past the famed Alcatraz prison as well as seeing the Golden Gate Bridge in the distance(we’d be going over the GGB later to get home). Once we reached Sausalito, we had about an hour of time available before our reservation at Poggio, so we all went our separate ways to browse the local shops. This is really the first and only time I spent any money on something other than some coffee or airport food. However, what I did buy was candy, mostly salt water taffy, but also some other hard candies, including Atomic War Heads. Dinner at Poggio was extremely nice and easily the most expensive meal we had together. I went with a very tasty Margherita pizza and beer from Drake’s Brewery. After dinner and much non-business conversation, we took a taxi ride back to the hotel. Once again, we all agreed to meet in the lobby at 8:30am to make our way to the office for our last day together.

Sunday

The last day was pretty straightforward. We kept at it, doing what we could and getting stuff done. Lunch was pizza. Early in the afternoon our first person left, but the rest of us remained. We ended the work day with one last group discussion and thanks for all of the hard work that everyone put in. We originally didn’t have a set plan for that evening, but by the time sunday afternoon came around, we were all ready to find a bar and just kick back and relax together one last time. We made our way over to 21st Amendment Brewery in San Francisco, and had dinner and beverages. This location provided what ended up being my favorite beer the entire weekend. The name was “Monk’s Blood” and I found it extremely tasty. Sadly, it is not available in South Dakota, and 21st Amendment’s website mentioned that the brew will be going into hibernation in the near future. Finally we all made our way back to the hotel for the last time. I opted to stay in my room the rest of the night due to being tired from the long but productive weekend. My flight was scheduled for 10:50am the next morning. Due to three of our group having flights near the same time, and one of us having rented a car, we traveled to the airport in the morning together.

Conclusion

Overall, I am extremely happy with how everything went and enjoyed every minute of the trip. I am appreciative and thankful that Mozilla would be willing to provide the ability for their community members to get together and help make the internet a better place. Hopefully I can participate again in person in future doc sprints. If not, then there’s always remote help. If you are curious about details regarding who worked on what, you can read the official summary of the weekend at Mozilla Hacks.

What is the GMaiOSDtMC Fund? It is the “Get Michael an iOS device that makes calls” fund. However, this is more than just a story about “fundraising” for a trendy phone. This is a story about how awesome and amazing the internet is. I will be the first to admit that it wasn’t a very serious thing, at first. I tweeted about it and wasn’t expecting much. This is especially true since I believe I first mentioned it at all on April Fool’s Day. To make sure it wasn’t instantly dismissed, I made sure to note it wasn’t a joke tweet, I just didn’t think much would ever come of it. Who would donate money to someone they barely know, for something like a phone? Right?

By Wednesday night, I had my list of people who had donated, willingly. There were 9 people in all, spanning three corners of the world, from the US to Europe to Australia. Their donations were in the range of $3, all the way up to $30, totaling $118. I meant to have a cap of $100, but the last donor decided to use playful blackmail by threatening to never play DrawSomething with me again if I sent any back. Who am I to argue? The following people are the 9 very generous donors, in no particular order. Most have twitter accounts that you can find by clicking on their name, if you want to follow them, and most are people who work to make the internet a better place, every day.

• Jacine Luisi — New York, USA
• Paul Maloney — Liverpool, UK
• Mika Epstein — Illinois, USA
• Rachel Baker — Illinois, USA
• Jonathan Dingman — California, USA
• Ryan McCue — Australia
• Tyrel Kelsey — Utah, USA
• Misty W. (e-step sister) — Minnesota, USA
• Grace Smith — Northern Ireland

I can not express exactly how humbled I am by these individuals. I am not sure why they donated what they did either. My two best guesses are that it’s because my intentions were for a iPhone, which I know has a lot of fans, and because of who I am. Someone that they’ve interacted with as best as possible can be online, and they felt was worthy of some of their hard earned money. No matter their reasons, once again I thank them. If any of you need me for a guinea pig for anything you’re working on, or need me to look things over and give critiques, do not hesitate to ask. I am in your debt.

I have seen, time and time again, especially in the past year, that the internet is full of wonderful, kind, helpful people. From this current example, all the way back to last year when I initially jumped into the freelance pool, they have been there for me, supporting me every way they can. This week is just the latest example. Hopefully I can pay it forward soon.

Earlier today in the WordPress IRC help channel, someone asked the question about what’s the “best” web traffic and analytics plugin that anyone knew about. I was answering with Google Analytics as that’s what I used and had low issue with. However, someone else mentioned Piwik, and being the curious type, I checked it out.

It all looked standard fare and what I’d expect out of web analytics. However, I stumbled across this bullet point and that more or less sold me on trying it out.

You own your web analytics data: because Piwik is installed on your server, the data is stored in your own database and you can get all the statistics using the powerful Piwik Analytics API.

I really liked the idea of owning my own traffic data instead of having it all reside on Google’s server. Over time, I’ve grown to become more suspicious of what they are and could be doing with the data they have on me. While I know I can’t avoid them completely, gmail for example and android smartphones, I can limit what they have on me in other areas. I no longer use them as my default search either, I’ve moved over to Duck Duck Go.

Nonetheless, we’ll see exactly how well I end up liking Piwik, but from what I’ve seen so far, I will likely remain happy for a long while, and retain my own data.

The sandwich is, without question, the best thing ever discovered by man (suck it, penicillin!), and bread is the most dedicated soldier in the sandwich’s army. Bread makes it possible for loose meats and stray condiments to transcend their differences, to come together and celebrate their tastiness in an organized and mutually beneficial fashion. It brings order to your fridge; without the bread’s stern but fair confines, what would keep your deli meats in line? Or your peanut butter and jelly? You’d have to just eat a spoonful of peanut butter and then desperately chase it with a shot of jelly. You’d be pounding fistfuls of various meats into your maw and chugging Grey Poupon just to feel something. Bread fixes all that and keeps your food safe and easily transportable. It’s like an edible envelope that mails food letters straight to your mouth.

Read more: 9 Ridiculous Cooking Myths You Probably Believe | Cracked.com http://www.cracked.com/article_19628_9-ridiculous-cooking-myths-you-probably-believe.html

This is an evolving list I’m sure, but I just wanted to get the initial one out the door. Feel free to add suggestions in the comments.

• Move myself up to a more competitive position in rates
• Better understand javascript and jquery
• get my finances to a point of stability and being able to afford the same perks that an traditional employer offers
• Vote in the South Dakota Primary Elections this summer, for the only candidate worth their weight in gold.
• Get at least three patches into the core code for WordPress
• Help make top-notch documentation for WordPress in their theme/plugin development areas of the Codex
• Help make top-notch documentation for the Mozilla Developer Network
• Locally network more and meet new people, both personally and professionally.
• Launch Hand.Writtentweets, my too long touted idea.
• Get this site here on an original design
• Drop support for IE7 in my freelance work
• Meet at least one of the WordPress Core commiters
• Attend a big-time WordCamp

I was curious to see what each current Presidential candidate used for their website management and which doctype they used. So I went on a little bit of view-source hunting. Candidates checked on:

• Ron Paul
• Mitt Romney
• Michele Bachmann
• Rick Santorum
• Jon Huntsman
• Newt Gingrich
• Rick Perry
• Gary Johnson

Here are the results for each:

• Ron Paul: WordPress with xhtml Strict
• Mitt Romney: Drupal with xhtml Strict
• Michele Bachmann: WordPress with xhtml Transitional
• Rick Santorum: Drupal with xhtml Strict
• Jon Huntsman: Expression Engine with xhtml Strict
• Newt Gingrich: Drupal with xhtml Transitional
• Rick Perry: WordPress with html5
• Gary Johnson: WordPress with html5

Noteworthy spots: none of them use Joomla. Huntsman dared to venture away from the WordPress/Drupal crowd. Perry and Johnson are both using both of my preferred choices.

If I was voting strictly based on CMS+Doctype, Johnson would win hands down, with WordPress and the html5 doctype. However, Johnson is in the same position that Ron Paul was in, circa 2008. Even though, from what I’ve seen of Johnson, I think he’d do a lot of good and bring a lot of sanity back to Washington, when it comes down to it, my vote is going to be for Ron Paul. Too much of me agrees with what Ron Paul has been saying, to pass up on the chance right now.