Month: May 2014

A Tale of Technology in Three Generations

My grandfather could probably have told you how many electric motors he owned. There was one in the car, one in the fridge, one in his drill and so on.

My father, when I was a child, might have struggled to list all the motors he owned (how many, exactly, are in a car?) but could have told you how many devices were in the house that had a chip in.

Today, I have no idea how many devices I own with a chip, but I could tell you how many have a network connection. And I doubt my children will know that, in their turn.

The entire column about the Internet of Things is insightful, as per usual for a Benedict Evans piece, but I’d like to point out his brilliant way to write an opening.

Life Advice from Mike Rowe

And most of all, stop worrying about your happiness. Happiness does not come from a job. It comes from knowing what you truly value, and behaving in a way that’s consistent with those beliefs.

Many people today resent the suggestion that they’re in charge of the way the feel. But trust me, Parker. Those people are mistaken. That was a big lesson from Dirty Jobs, and I learned it several hundred times before it stuck. What you do, who you’re with, and how you feel about the world around you, is completely up to you.

From Mike Rowe’s excellent life advice.

Verbosity in Support Forum Replies

After volunteering on the WordPress.com support forums for a bit, one question keeps coming to my mind. “How long should my answer reply be?”

Because if need be I can be really, really verbose. I can explain how a question can be answered, and then add that the solution is not effective anyway and then add a better alternative, and then some. I can answer a question, then add a list of canned answers about future issues that might be asked, that might or might not be happened, but just in case, here are the answers anyway.

Or I can just say hi and then write a link to a particular documentation page and leave.

What is the sweet spot on this?

If the main objective is speed, then logically single line replies are best. Just write an answer that directly solves the question. Bam. It’s quick, the person who asks is satisfied, and I don’t have to waste time crafting long answers, time that can be better used answering others.

But this can’t be ideal in many situations. Oftentimes the question itself is suspect. Someone wanted to do something, but she didn’t know that doing so could bring an issue to her site. Trying to upload a really garish background image that will make the entire site unreadable, for instance. A single line reply can show her how to do that, but it’s better to understand first what she’s trying to do, and then explain why it’s a bad idea, and finally give a better alternative for what she’s trying to do (“Maybe get another background image? Here’s a link to a site that offers cool, subtle background images”).

So we can conclude that trying to understand what someone tries to do is more important than just giving him what he asks for. The downside is that it takes more time. This means that if we do this, we’re essentially sacrificing other users. To give you a good help, you will have to wait a little bit for it.

But perhaps, perhaps, waiting is not a bad thing. Unless it is an emergency, then a user probably does not mind waiting. Surely it is better to wait a little bit more for an answer that’s thoughtful and well-crafted, instead of an answer that’s quick but misleading?

Finally, what to do in case of emergency? Surely it needs to be solved fast, but first of all it’s important to be sure that the issue is indeed an emergency. Some users will say that all their issues are urgent, but those issues will of course have to be understood objectively first before an emergency action is done. And that understanding can be part of the phase where we try to understand what someone tries to do, two paragraphs before this.

Aside from all that, there are two other cases that I’ve found that can be used as a consideration.

The first is when someone mentioned that they’re trying to learn something. Like CSS customization, for example. In that case, it’s a good idea to not just provide an answer, but also adds a few things that can help her learn things better. I’ve explained how ‘!important’ works in a CSS thread, for example. That wasn’t necessary to solve the problem, but would be good to know for the person who asked.

The second case is when a question seems to be something that will be Googled a lot in the future, or it’s a unique issue with multiple facets of solution. Something that can be explained simply to normal users, but with technical gotchas that you might want to include for more advanced users. In this case, I will try to be quite verbose. I’ll add something like “you don’t have to read this, but just in case someone is interested…”, then include plenty of keywords, code snippets, anything to aid searchability and to actually explain the finer details.

That is the cool thing about forums, by the way. When you answer someone, you are also potentially answering someone else in the future. Someone might Google it and arrive at your answer, and then leave with a solution. It’s a good thing to keep in mind, whether you might have something to say to other people in the future with the same question.

So the rough algorithm will be like this:

Read the question, truly try to understand what happened and what the user is trying to achieve. Never write an answer before getting this understanding.

If turns out it’s an emergency, be quick to answer and put more importance on this.

If it isn’t, then see if the solution if harmful. If yes, take the time to explain and offer better alternatives. Mailchimp’s Voice and Tone site has good suggestions with regards to failure message, which to me is close to how an emergency situation should be handled.

If the question is harmless and can be solved quickly without the need of any extraneous info, then write a concise answer and keep it from being too verbose.

Additionally, if it sounds like the user is trying to learn something, it doesn’t hurt to add a bit more explanation to help her understand thing.

Finally, if the issue has multiple aspects to its answer that are not relevant to the current user who asks, but might be relevant to others in the future, be sure to include that.

So, Column It Is

If asked to describe Daring Fireball with just one word, I would not choose weblog. Rather, I would call it a column. Given a few more words, I would call it as a Mac column in the form of a weblog. To me, the two great formats for writers are the book and the column, in the same way that the two great foot races are the marathon and the sprint.

A good columnist establishes a rhythm, writes with a distinctive voice, and connects to a regular readership. That’s exactly what I’m striving for here. I don’t want to publish it anywhere but right here, on my site. Daring Fireball is more than just words; it is an entire presentation.

This is from John Gruber’s old post.

I’ve been having some thoughts about what type of writing I’m trying to have this site. From the start I did not view this place as a blog, because a blog evokes a personal diary kind of feel that I definitely am not trying to have here. For a while I set up the site with two categories of content: Article and Excerpt. Gruber’s post above clicked a certain part in my brain and made me think, “yes, that’s the kind of thing I’m trying to write.”

Then I’m not quite sure what’s the difference between an article and column, so I did some research. Answers.com (which I won’t link to) says that ‘Article is “objective” in its nature while Column is “subjective in its nature.‘ As Answers.com is not that trustworty as a reference, I looked up Wikipedia and turned out the pages about Article and Column more or less confirmed the idea. That’s good enough, so now I’m changing the category to Column.

More importantly, though, I have to think about the rhythm and presentation parts that Gruber mentioned. Sometimes when I visit sites like Gruber’s or Kottke’s, they certainly evoke a certain kind of feel (for lack of better word), despite their minimalism. You go to their site and you just can feel it. You can feel the author speaking, the thought, the curation, the efforts. I think I already got the minimalism look right on the site, but substantially it’s very lacking. This is what I should be working on next.

From Forums to Dedicated Ticketing System

Forums can be extremely difficult to manage, and my support forums were no exception. It’s easy to lose track of tickets and even easier for tickets to get off track as multiple users jump into threads with their own questions.

Pippin Williamson, founder of the popular Easy Digital Downloads plugin, decided to move from using bbPress forum to Help Scout as a main support channel.

This is interesting to me because I’ve been volunteering on the WordPress.com support forums for the last few months. I found that a forum thread is great for quick questions, but communication quickly become unmanageable for complex and long issues with multiple posters.

The forums will remain public and anyone can access them. All tickets over the last 4 years are there and everyone is welcome (and encouraged) to search them for solutions to any problems.

Openness and complete archiving are two of a forum’s main strength as a support channel, now that I’ve actually have the experience working with the medium. Kudos for Pippins for keeping the forum public.