Verbosity in Support Forum Replies

After volunteering on the 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. (which I won’t link to) says that ‘Article is “objective” in its nature while Column is “subjective in its nature.‘ As 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.

Changing Domain with WordPress

Originally this site used the domain. I bought the domain over at, which I found to have the lowest price for .io (39US$ at the time). The problem came a few months later when I tried to renew the domain.

As it turned out, .io domains could not be renewed at any time. Instead, domain owners are given the chance to renew starting from one month before the domain expires. I understand that there are some business reasons why this is so, but this is annoying from a customer standpoint. The limited renewal time window is worrisome because there’s a possibility that I miss the notification; this had happened before with an old domain of mine. Additionally, the domain can only be renewed for a maximum of two years in the future. This makes it a bit more complicated if I want to keep the domain for a long time.

Then I realized that I had an unused .im domain laying around, and decided to use that instead. .im’s are cheap, can be renewed at any time, and is just as short.

The domain change process itself was relatively simple. First, as I’m using Webfaction, it was easy to point a new domain to the same WordPress install. Add a simple DNS change and done. After waiting a day for the DNS to propagate, both and pointed to the same WordPress install.

The Codex gives four options to do a URL change. The one with wp-config.php is pretty simple, but it hardcodes values to the site and I didn’t want to do that.

The function.php method is silly (“So, you use your theme to change the URL of your site?”). It’s a bit hack-ish to load the site once and only once for the function to work, and make sure to delete it afterwards before someone loads the site and triggers the function again. I ended up using this method, though, because I knew what I was doing and the site was not getting any traffic during the process.

Afterwards, everything was running normally.

Just to be safe, I used Velvet Blues Update URLs plugin to seek-and-replace any instance of to That’s about all I did to move my site to another domain name.

For a big site there might be more works that needs to be done. Like redirections, to ensure that the site’s search engine rank is preserved and that visitors with old bookmarks don’t get stranded. My site is a very young, low-traffic site, though, and traffic is not important. It’s likely that this site will have to start over SEO-wise, but that’s fine.

What Flappy Bird Does Right

  • The first time you tap on the “Get Ready” screen, Flappy (assuming it is its name) jumps immediately. Instant feedback.
  • Once you do that first tap, Flappy drops quickly, urging you to tap again and find your rhythm.
  • The game over screen does many things right at once. The empty medal intrigues. The score and best score field constantly urge you to try again.
  • It only takes two taps from the Game Over screen to be playing again. One second, or less.
  • It only takes less than four seconds from playing to the first pipe.
  • The variation in pipe heights never seem impossible.
  • The art style immediately charms you, as the style is likely already impressed into your subconsciousness for years and years as part of Super Mario Bros, one of the most popular video games ever (so popular that I feel a little silly having to mention its name).
  • Same with the coin plink sound effect.

On Quoting Other People

Recently, Rands posted a brilliant piece about making, “The Builder’s High”. I wanted to quote and put it here, but before I had time, John Gruber and Marco Arment did that first. It’s interesting to note which part of the writing they decided to quote. Gruber picked this:

The things we’re giving to the future are feeling increasingly unintentional and irrelevant.

While Marco chose this:

Is there a Facebook update that compares to building a thing? No, but I’d argue that 82 Facebook updates, 312 tweets, and all those delicious Instagram updates are giving you the same chemical impression that you’ve accomplished something of value. Whether it’s all the consumption or the sense of feeling busy, these micro-highs will never equal the high when you’ve actually built.

I’ve never really thought about what to choose to quote. In previous posts I mostly just chose what sounded cool. For this Rands piece, for example, I was going to go with this sentence, because of its delightful flow and sonority:

You’re fucking swimming in everyone else’s moments, likes, and tweets and during these moments of consumption you are coming to believe that their brief interestingness to others makes it somehow relevant to you and worth your time.

Noticing how others picked the quote got me thinking. Gruber’s was short and didn’t directly convey what the article was about. But it is intriguing. Marco, on the other hand, picked a paragraph that did a great job showing how consuming social media noises and the act of building did something similar—but ultimately not even close—to our mind. If the goal is to give the reader a summary of an article, Marco did the best job between us three.

I’m not sure what’s the conclusion here. But I sure am going to think more whenever I write these quote posts.

Some Gems on Delegating

John D Cook, “Whether to Delegate”:

You shouldn’t necessarily do things that you’re good at.

(I love it when an article provokes the mind right from the start.)

Managing energy is more important than managing time. Energy is what gets things done, and time is only a crude surrogate for energy. Instead of only looking at what you could earn per hour versus what you could hire someone else for per hour, consider the energy it would take you to do something versus the energy it would free to delegate it.

If something saps your energy and puts you in a bad mood, delegate it even if you have to pay someone more to do it than it would cost you do to yourself. And if something gives you energy, maybe you should do it yourself even if someone else could do it cheaper.

Miles Richardson, “Why Coding is not the Best Use of Your Time”:

I used to code everything myself. “If you want something done right, you gotta do it yourself,” I used to say. Wrong. If you want something done right, you just need to know how to tell someone to do it.

Now, I turn projects into well-written specs with clear directives. I break them down by tasks, and then group the tasks by specialty. This way, instead of spinning my own wheels 90% researching and learning, and 10% building, I can hand the spec to a specialist who already has the requisite background knowledge.

If you are a generalist, I highly recommend this approach. It will significantly improve your efficiency.

How to Write

When writing something that matters, there are at minimum two steps involved.

The first step is the act of dumping down all thoughts and informations in one place. In this step, the brain needs to be as open as possible to better find connections between ideas. Accordingly, the analytical part of the brain that deals with the correctness of the language and the structure and overall quality of the final product needs to be turned off. The brain needs to explore as far as it can, unhindered from rules.

The second step is sculpting. This is when the analytical part of the brain is allowed to wake up and do its job: shape the language, cut the unnecessary weight, alter the flow, challenge the logic.

Thoughts on App Store Pricing

An interesting thread discussing App Store pricing on Hacker News. There’s an unfortunate amount of noise on Hacker News nowadays, so here’s an attempt to collect the few good signals. Emphasizes and formatting are mine.

wisty argues that a good pricing strategy is to give plenty of information to customers first:

[…] when customers have very limited information, and side-by-side pricing, they’ll always minimise risk by getting the cheapest app. The cheapest app is free. And eyeballing statistics on sales, $1 apps don’t do any better than $2 ones (depending on the platform and app – iPhone buyers can be very elastic). Many customers aren’t so stingy they’ll balk at paying an extra dollar, they simply flock to free apps because you can’t beat free. Especially for an app which has lots of substitutes (todos, games).

If customers have good information (they are already using the app), and only one price (your IAP), or pricing you control (your IAP, with dummy prices – feature by feature unlocks, and maybe a premium feature or two), they’ll be more likely to spend money.

The big money is in exploitive IAP. Skinner box games which use psychological tricks to goad big-spending “whales” (addicts) into spending more. But the small money is probably in IAP too – unlocking the demo.

There’s no money (IMO) in $1 apps – they are too expensive (compared to free apps), and they sell themselves short.

clarky07 points out that despite the race-to-the-bottom situation, people do pay for apps:

[…] the overarching point that isn’t really spelled out, is that people do actually spend money on apps. There are important pricing considerations in that going from .99 to 1.99 you don’t normally lose >50% of buyers. Once you’ve crossed the barrier from free to paid, another dollar isn’t a big deal.

Also, IAP and other methods of giving people trials helps. Overall the point is though that people do in fact spend money on apps.

jonnathanson suggests a freemium model:

Big game publishers can afford to give out their games for free, then harvest millions of dollars a week from in-app purchases, pour that money back into paid user acquisition, top the charts, and repeat until their next game comes out.

That business model is all well and good if you’re a game publisher, and especially if you’re a well-funded game publisher. But it kind of sucks for anyone who’s not in a category that benefits so dramatically from in-app purchases. In-app purchases are not a magic-bullet solution to pricing problems for most other categories of apps.

(Now, one could certainly argue that games provide more value to the user than other apps do. While there’s something to that argument, it’s not sufficient. Surely the solution to this problem isn’t “every app becomes a game”).

So what should you do if you’re an app developer, and you’re not making a game? To be honest, you’re in a tough spot. The deck is stacked against you. Prices are converging on zero, in-app purchases probably won’t keep the lights on, and the prospect of flooding your app with advertisements probably makes you (or your UX designer) cringe.

This is where the freemium model should make sense, IMO. Create something of general value to a large TAM, but of extraordinary value to a smaller slice of that TAM. Give away the basic version to the TAM, but upsell the power version to the power users. It may be the case that your app is better for the power users than existing solutions for which they’re paying hundreds, or even thousands of dollars. If that’s the case, don’t be afraid to charge higher than $.99 for the premium version.

If the delta in utility between Your App and Existing Solution is extremely high, and the price gap between Existing Solution and Your App is big, you’ve got a lot of room in pricing, and that pricing will be justified.

Unfortunately, absent a fantastic way to do trial versioning, the existing methods are pretty inelegant. Apple needs to get better about allowing developers to do trial versions, or this overall pricing and monetization problem is going to get worse.

NateDad suggests that an app should be part of a bigger service, ideally with recurring payments:

If your paid app can’t compete against a free app… that’s hardly the fault of the user or the app store. It’s the fault of the app maker. What you’re basically saying is “my app is so easy to make, that someone could make it without even caring to get paid for it”.

It’s competition. Yes, if someone can recreate your application for free, then your application wasn’t as valuable as you think it was, by definition. Make a better app, or turn it into a service that generates revenue past app deployment.

I think many app developers have gotten spoiled by tales of people getting rich off of P.O.S. apps, and expecting that to happen to them. That happened back in the day because there was a scarcity of applications and app developers. That scarcity no longer exists. Most of the easy stuff has been done, and a lot of free versions have been made because, let’s face it, most apps really aren’t terribly complex.

So, make something big and hard to duplicate. Make it part of a service you provide with recurring charges and give away your app. It’s a better model, anyway.

Touche adds that developers should stop making trivial apps:

I have my doubts that prices are going anywhere but down. You can stubbornly keep your app’s price high if you want but a couple of dozen others will gladly step in your place.

I think the author is wrong here; apps do offer real value but they are still close to being worthless economically. What developers should start realizing is they shouldn’t spend so much effort on todo lists, podcast clients, rss readers, or any other trivial app category that many people do as side projects for free for fun.

As a result we might get more genuinely innovative apps as developers look more closely at what niches are being underserved.

kemiller offers an opinion about the relationship between apps and customer attention:

I have a somewhat different perspective on this. Apps cost people something much more valuable than the small amounts of money in question: attention. Most people find learning new software to be a chore. So every app they download has a cost in attention, in learning how to use it, however simple that might be, and some of them have a cost in money as well.

If the app is free, they know they can abandon it instantly if it doesn’t give them value right away, and lose almost nothing. If it costs money, they will feel obliged to get more value out of it, but that means committing to spend even more attention.

When you buy a cup of coffee, you’re getting attention back because someone else is taking on the slightly fiddly business of making coffee, and once you have it, there is nothing to learn, you can just enjoy it.

Viewing software transactions as paying attention, rather than money, for value, makes a lot of these markets make more sense. Because if you offer something that will reduce the net amount of attention they have to pay, they’ll often gladly give you money for it.

macspoofing pretty much concludes the whole thing:

The 99c app business, is shit-business. I feel for app developers. You can’t build a company around that price point. Either you charge more or you go down the recurring revenue model. Neither is easy. If you’re a game developer you go freemium, and you try to squeeze as much revenue out of your customer base.


Lessons From an Accidental Twitter Campaign

It started when I noticed that the iQuran iOS app was discounted from its usual $5.99 price down to $1.99. The app was pretty much the de facto best Qur’an app available for iOS, and that discounted price was incredible compared to the amount of information, polish, and care that went into it.

Without thinking much, I went to Twitter and offered my followers to gift them a copy of iQuran, free, no question asked.


Now, I am just a common Twitter user, nobody famous, and my followers are mostly just friends and families. What I didn’t expect was that a couple of famous Twitter users found out about my tweet. These guys had a lot of followers in my country, and with that, a lot of influence.

After the dusts were settled, the tweet ended up with 80 retweets, with more than 70 people requested a copy of iQuran for their iOS devices. It was truly an overwhelming surprise for me, but thanks to a friend, Nizamil Putra, we ended up joining forces and created a separate Twitter account (@freeiQuran) to handle the deluge of requests.

Here are some lessons that sticks out to me after the experience:

Viral effect is unpredictable, prepare for the best

The number of requests were simply beyond our imagination. A retweet from a big influencer can affect the reach of a campaign immensely. We were fortunate enough to be able to afford the cost of the whole campaign. However, had another one or two influencers spread the tweet as well, things will get a lot more overwhelming.

It’s difficult to handle a lot of interactions in a short amount of time with the default Twitter apps

We got a lot of replies in a short amount of time, and it was hard to keep track of them. There was no way to mark a reply as read, and while I tried to keep up by copy-and-pasting people’s data to Google Spreadsheet, new mentions kept coming in. The real-time nature of Twitter makes it hard to keep track of things.

In hindsight, it is probably better to handle the data *after* the campaign is done. Which brings us to the next two points:

Have a clearly defined campaign terms and limits

My tweet was not intended to “the outer world”, so to speak, so I didn’t really limit how many gifts to send and how long my offer should stand. When it explode, it became clear that things would be better if we had a clearly defined terms and limits beforehand.

This isn’t just to help keep the campaign starter’s sanity. We also had a bunch of questions from people asking about the validity of the terms, and other things. This added more to our tasks, and having the terms ready should have helped eliminate that.

If you want to gather data from Twitter users, use alternative methods instead of using Twitter mentions

The default Twitter apps were not designed to help us process a lot of rapid information at once. After certain update per minute, it simply is not possible for human mind to keep up. Therefore, if with the campaign you want to gather data from Twitter users, don’t do it via mentions.

Something like a custom Wufoo form should be a good help, or even a simple Google Docs form that saves information directly into a spreadsheet.

When more than one person handle a Twitter account, things get messy quickly

Nizamil Putra and I both used the @freeiQuran account to communicate with the requesters. There were times when I replied to a question that were already answered by Nizamil, and vice versa. There were no clear indication that a tweet was already replied, so we overlapped each other a lot. I’m still not quite sure what’s the best solution for this.

Really famous people have it hard on Twitter

The experience also showed me a glimpse of the daily life of famous Twitter users. Once you have a lot of followers, the number of mentions will clog up your mention tab very quickly. If someone has an important mention for you, it will be hard to notice it. It doesn’t seem like Twitter is designed from the built-up to handle that edge case, yet. There’s probably a business to be made here.

Those are the lessons I can extract from the experience. To conclude, Twitter is a great tool to do a campaign and spread a message, but be prepared to think of various ways to help you if you want to *organize* it.

On Sidebars

Generally there are two types of sidebar on a website: the one with contents relating to the main content on the current page, and the one with contents relating to the entire website.

The classic WordPress widgets examples are the building blocks of the latter type of sidebar: “Recent Posts”, “Categories”, “Archives”, “Meta”. Meanwhile, examples of the relatively rare example of the former type are related videos (as in YouTube), quote highlights in interview articles, footnotes placed to the side of its corresponding sentence, or even comments (as can be seen in Medium’s brilliant context-specific commenting system).

I appreciate the former type much, much more than the latter. Website-related sidebars, especially when poorly designed, often distract instead of support the main content. This is especially true on single article pages, which oftentimes is the most frequently visited area in a website, not the homepage.

On the other hand, the former type of sidebar adds to the content instead of substract attention from it. It adds immersion. It can gently leads to other parts of the website, whereas website-related sidebars can feel forced at times (“Like my coding article? Take a look at my Personal posts category? No? How about the archive from December 2002?”).

Understandably, it requires more effort to develop a system where sidebar contents can always support the main content. It’s not always easy to gather supporting contents. In that case, instead of a fixed sidebar area, a flexible asides system can be employed. An example can be seen in The Great Discontent.

As for website-related sidebar contents? I feel that the footer area can be best employed for those. It doesn’t get in the way of the main article, but it’s always there whenever somone needs it.

Start Ugly Things

[white_box] This article was first featured in Medium’s Editors Pick. [/white_box]

I have a bad case of analysis paralysis. When I make something, I want it to be great. I want to see it from many different angles. Weigh all my options. Cover all ground.

Needless to say, I end up not making a whole lot of things.

One day I wanted to know what it’s like to work with a different mindset. I made up an experimental mindset where I allow myself to be ugly, to be maker of ugly things.

Everything went better than expected.

I tested that mindset with this idea I had for a website. I purposely told myself not to give a damn about its design. I generated the site’s color scheme from a picture I liked. A good friend of mine offered to design a logo for it and I used it without thinking twice. I just wanted to launch.

And so, in less than a week, Freebbble was born.

Initially, it was painful. I cut corners everywhere; functionalities were duct-taped together. And knowing it made me feel bad. I knew I could’ve done better. The site could’ve been prettier.

But as more people came to visit and used the site, I found that the site’s flaws, glaring as they may seemed to me, didn’t even bother anyone. Nobody complained that the layout was imperfect on mobile view. They didn’t know that the theme’s code was lacking many page templates and that in the back-end different content types were cobbled together.

It just didn’t matter. People kept coming and using it.

Another thing I realized was that I was more motivated working on the site once it launched. Turns out it’s easier for me to love something real than to love a vague idea. And that love, combined with the fact that I got actual people using the site, gave me the push to continuously improve that ugly thing.

This article is also written on a whim. Previously I have written two other articles, but I made the mistake of wanting them to be perfect. They’ve now been sitting in draft for I won’t know how long.

This article is ugly; it doesn’t flow as much as I want it to. But it’s here, and you can read it. I’ll improve it and write something better later. But that something better won’t be there, unless I have this ugly article here first.

So that’s the lesson I learned.

Start ugly things.