tumblilarius lukhnos

Lithoglyphics: LadyBugz 1.6.9: More Bug Fixes

Thu, 19 Aug 2010 20:22:33 +0800

Lithoglyphics: LadyBugz 1.6.9: More Bug Fixes:

We’ve just released LadyBugz 1.6.9. It turns out that 1.6.7 didn’t completely fix the crashing bugs, and from the crash reports we’ve received (thanks everyone for letting us know!), it concentrated in one specific area. We’ve revamped that part of the code, and version 1.6.9 should clear that issue now.

Another Mile to Go in the GC-back-to-NonGC Transition

Sun, 08 Aug 2010 15:25:00 +0800

Another Mile to Go in the GC-back-to-NonGC Transition:

From Lithoglyphics, the blog of my company:

We have just released LadyBugz 1.6.6, available from our website and through auto update.

After we released LadyBugz 1.6.1, we have received a number of bug reports that it crashed at various places. We realized that our garbage collection transition was not completely done, and there were loose ends that we overlooked. We take those issues seriously, and after a week of testing, we believe 1.6.6 should behave way better.

I have written previously why we chose to go back from garbage collection to manual memory management, and while it was absolutely necessary, I really wish we could have found the crashing bugs earlier with a broader range of testing data set. Quitting the perks of garbage collection is a hard process (not having to worry about complex object relationship and ownership is especially addictive), and hard-to-reproduce crashing bugs suck. We have learned a thing or two the hard way.

Cyclic Retention Pitfall in Objective-C Blocks

Tue, 03 Aug 2010 16:20:00 +0800

Is it tempting to write the following code:

    NSBlockOperation *op = [[[NSBlockOperation alloc] init] autorelease];

    [op addExecutionBlock:^(void) {
        if (![op isCancelled]) {
            // run the block if the operation is not cancelled
        }
    }];

    [someOperationQueue addOperation:op];

If you don’t use garbage collection (gc), the snippet above will eat up memory, and the Leaks Instrument will not be able to discover it as a leak. Why?

In Objective-C, blocks behave like objects. In non-gc runtime, they have retain count, can be copied¹ and must be released when you want to discard them.

When a block is created, it implicitly retains every Objective-C object referenced in its scope. When the block is deallocated, it sends -release to all those retained objects. In Objective-C, those extra calls are done for you by the compiler. If you set breakpoints to -retain and -release, you’ll be able to observe this behavior as blocks are created or deallocated.

Usually you don’t need to worry about those things, and that’s how you can use blocks as good closures that many other modern languages have.

But here’s the problem: Because blocks only send -release when they are deallocated, not when their scope exits, it is possible for them to retain the objects which retain them. The code snippet above is a case in point. The NSBlockOperation object op retains an execution block, but then the block implicitly retains op. The result of such cyclic retention is that the retain count of op will never reach zero, and hence op will eat up a chuck of unreclaimable memory. And because op is retained by another object, it is not a lone wanderer that you forget to call -release, therefore the Leaks Instrument will never discover it as a leak.

A solution to this problem would be:

    NSBlockOperation *op = [[[NSBlockOperation alloc] init] autorelease];

    NSValue *weakOpValue = [NSValue valueWithNonretainedObject:op];
    [op addExecutionBlock:^(void) {
        if (![[weakOpValue nonretainedObjectValue] isCancelled]) {
            // run the block if the operation is not cancelled
        }
    }];

    [someOperationQueue addOperation:op];

The NSValue object used above is effectively a weak reference to op. This breaks the retention cycle, so the -dealloc of op will now be called, and the block will also be released.

Cyclic retention is not a problem for Objective-C runtime’s garbage collector, so the first code snippet will not be a problem if you use gc.

Another incomplete solution is for Apple to change the timing of calling -release in a block. Releasing retained objects when a block exits seems to be a reasonable expectation. But, given the nature of the use case above (an NSBlockOperation might never get executed), plus the fact that referenced objects must be retained before a block is entered, it’s not an encompassing solution, although it would make blocks behave more to such expectation.

One final note: Because of the potential risk of cyclic retention, you must be very careful if you use blocks within a block. This is one place where gc can liberate us from such a blocking issue (pun intended), but gc is not available on the iOS and has its issues on Mac, too.

But not retained. The reason is that when a block is first created, its scope refers to the values residing in the nearest outer scope on the stack. If you toss it around (i.e. passing it as an object), it must first make a (const) copy of those values onto the heap. If you just retain a block then pass it around, chances are it’s still referring to the stack. And you know what will happen when dangling stack references are passed around. ↩

As my favorite French saying goes, jamais deux sans trois, or...

Mon, 19 Jul 2010 20:18:00 +0800

As my favorite French saying goes, jamais deux sans trois, or literally in English, “never twice without thrice”.

Update: Replaced the video with a new version with English...

Mon, 19 Jul 2010 20:13:00 +0800

Update: Replaced the video with a new version with English subtitles.

Earlier this year, a Taiwanese newspaper, Apple Daily (蘋果日報, not affiliated with Apple Inc.), made an Animation News (動新聞) clip on the Jay Leno-Conan O’Brien spat, which I also re-posted. But Apple Daily’s real fame started with its animated Tiger Woods tabloid series.

Anyway, this is the new one on Apple’s Antennagate. And once again you don’t need to know any Mandarin Chinese (the official language in Taiwan) in order to understand the gist of the story. Now I must warn you not to eat or drink in front of your laptop while watching this clip…

Why My Next Mac App Will Not Use Garbage Collection

Mon, 19 Jul 2010 03:32:00 +0800

Among the many things I have learned from the past few years’ experience of developing desktop applications, here’s one: Implement your app conservatively. This often translates to using only proven technologies. Cocoa’s garbage collection (gc), alas, does not seem to be one of them. My next Mac app will not use garbage collection. In fact, we are actually even taking the pain of modifying an existing garbage collected app to non-gc.

Since Mac OS X 10.5, you can choose to use automatic garbage collection in your Cocoa app. Apple’s take on gc is a brilliant engineering feat, which makes Objective-C a more modern language (and it’s even open source). Before gc, memory management is much like manual transmission and requires a lot of mental arithmetic — you need to retain an object (to increase its refcount) when you start using it, and release it (to decrease its refcount) when you relinquish its ownership. With gc, no more such mental arithmetic is required. It’s great that you are saved the burden of memory management, particularly when you have other more nasty things to worry about, such as multithreading (which makes manual management harder) and binding (which complicates object graph).

Unfortunately, I have found a few instances that Cocoa’s gc doesn’t work that well. This has particularly to do with libraries that are beyond gc’s reach. I’ll name three: Secure Transport (which handles things like HTTPS), icucore (which handles localization and date/time formatting), and XML parsers (I have tried both NSXMLParser and expat). These three can already leak from time to time when being called from the main thread alone, and almost gurantee to leak if used in different threads, even if proper locks and one-instance-per-thread-at-a-time policies are enforced.

You might be tempted to think, big deal, if those stacks have their baggage and work best in a non-gc app, I’ll just write a separate app, and use distributed objects (DO), another fancy technology, to bridge between the gc and non-gc processes. Here’s the bad news: There is apparently a bug in Apple’s DO implementation under gc, and all proxies objects that ever created to communicate with the remote process will not be destroyed until the app’s termination.

So for the time being my conclusion is, if your app is network-intesive, needs to do a lot of things in parallel, and happens to parse a lot of XML and has a fairly complex user interface that relies on binding, then garbage collection probably isn’t for you.

Now the only big question that I have is, how did Xcode manage it? Xcode, as we know it, is a garbage collected app¹. It’s also said to be Apple’s most complicated application. Now, unlike Mail.app, Xcode doesn’t seem to do lots of date/time formatting. It reads plist (for which Apple has a faster parser implemetation) but not really XML. The only network-bound parts seem to be the documentation fetcher and the recently-added automatic iPhone provisioning. Much of the IDE seems to be there already in OS X 10.3 days. All told, Xcode seems to stand well.

I’d like to know to make those non-Cocoa parts work with gc. But before that, I’ll take the more conservative path.

I know this because the previous generation of our Adobe Kuler color picker, Mondrianum, used (and still uses) a cover flow image view, which doesn’t work under gc. In the previous generation, we used some NSGarbageCollector hacks (don’t ask) to manage to make the plug-in work within Xcode. In the current version we have decided not to support gc apps like Xcode, because those hacks never worked perfectly. ↩

LadyBugz 1.5

Mon, 19 Jul 2010 02:37:19 +0800

LadyBugz 1.5:

My company’s FogBugz client application for Mac, LadyBugz, has a new version. We have given the case history view a facelift, along with many improvements and bug fixes. We weren’t sure if we were on the right direction when we started to make the major interface change, so we asked a few of our customers if they’d like to try out a beta version. The initial response was positive, and so we sent the merge command, and the tentative branch became the main. This enables us to take on implementing other frequently requested features, and we believe this version is a substantial improvement.

A great example of the 30+ year old “Y/N” interface.

Sun, 13 Jun 2010 21:34:09 +0800

A great example of the 30+ year old “Y/N” interface.

SQLite Turns 10

Sun, 30 May 2010 19:14:00 +0800

D. Richard Hipp, creator of SQLite, in sqlite-users mailing list:

Some of the code in SQLite (such as the Lemon parser generator and the printf implementation) dates back to the late 1980s. But the core of SQLite was not started until 10 years ago. Ten years is not that long ago, though it has been long enough to amass 7114 check-ins - an average of 2.1 check-ins per day. If you are overseeing such a project, 10 years seems like forever. It has hard for me to remember a time when I wasn’t working on SQLite.

SQLite is my favorite software project and a role model. It is lightweight, efficient, self-contained, and vastly powerful. Not many software projects can be said of the all four, especially in terms of self-containedness. SQLite now states it status as public domain in a more official manner (out of institutional use considerations), but I believe all of us can learn a lot from the blessing in its source code:

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.

I also had the opportunity to work on a client project that used SQLite’s both paid versions—SEE and CEROD—and SQLite never disappointed.

I wish the best for the project, and look forward to its 20th and 30th birthdays.

Formosana, a Collection of C++ Libraries for Processing Taiwanese Languages

Fri, 07 May 2010 08:09:00 +0800

Formosana is a C++ library collection that provides basic building blocks for processing Taiwanese languages. Currently three languages are supported: Mandarin, Holo and Hakka. It also provides a language-agnostic, bigram-based word segmentation library. It has no external dependencies and can be built on most platforms I know of. It is available on github under the MIT License.

My day job is commercial iPhone and Mac software development. In addition to that, I also develop open source software, mostly in the form of libraries. Designing libraries and frameworks is both a good exercise in itself and an important part of software development. It pushes you to think and plan head for future consumption, and it also gives you a good opportunity to think about the fundamentals of a given problem set.

Formosana currently has three major components:

Formosa::Mandarin: A library for processing Mandarin syllables and handling text input keyboard layouts. An abstract data type represents Mandarin syllable. The syllable data type accepts both Pinyin and Bopomofo as input, and can be used to convert to either form as output. Its internal representation guarantees that the syllable in always in the CVCT form, although it does not guarantee that the produced syllable is always phonetically grammatical (i.e. it can be used to produce syllables not found in the actual Mandarin). It also support four major keyboard layouts (expandable) that map a standard US keyboard to Bopomofo symbols.
Formosa::TaiwaneseRomanization: A library for processing Romanized Holo and Hakka. An abstract data type represents Holo or Hakka syllable. Internally it uses POJ (pe̍h-oē-jī, also called Church Romanization by some). It accepts POJ for both input and output. Tâi-lô (TL, or Taiwanese Romanization System), technically a POJ variation that is the standard for Romanized Holo used by Taiwan’s Ministry of Education, can also be used as both input and output. This syllable library has a normalization member function that guarantees only the composed tonal mark is placed on the correct vowel character according to the resonance in the Holo language. It is weaker than its Mandarin counterpart in that the syllable class does not guarantee the represented syllable is always in the Initial+Vowel+Final+Tone form. It accepts both “composed” form (syllable with diacritics) and “uncomposed” form (tone in numerals, also called database query form in the library) for input, and can also produce output in either forms. This library also supports keyboard layout mappings. Both numerical tone input and dead key combinations are supported.
Formosa::Gramambular (literally, “gram walking”): A language-agnostic, bigram-based word segmentation library. It accepts an input set of weight unigram and bigram key-value pairs, and output a best-scored path. If the key is input syllables and value is a Chinese phrase that the syllables represent, the walk is an input method. If we reverse the key and value, it becomes a word segmentation tool. As the library works without any grammatical knowledge, the quality of the dictionary (that provides the data source for weighted nodes) is the deciding factor of the output quality. I have mentioned the principal of the library’s design in a talk at Open Source Developer Conference, Taipei, Taiwan, in 2008. As a bonus, Gramambular has a debug helper that can produce outputs in the Graphviz DOT format, which you can then feed into the tool and get visualizations like this and this.

Each of the components comes with its own demo code. I have also supplied Makefiles (for Mac OS X and other UNIX platforms) and Microsoft Visual C++ solution files for those sample projects.

The library collection makes use of a few helper classes from The OpenVanilla Project. I have included those class files (also written by me) in the source to make the collection buildable with no external dependencies.

Formosana was first designed for developing input methods, and both the Mandarin and the Taiwanese Romanization modules have been used in actual products. Although Gramambular has not yet been used in production, I have previously worked on an implementation based on similar principles for an internal project at my company. The commit history of the project will tell you that Gramambular was written pretty fast (2 days) from ground-up. For me it was also an exercise to start over from scratch to see if the design is solid.

The library collection has many other uses in processing Taiwanese languages. There is also space for improvement. For example, a syllable class that can validate against the phonetic grammar is highly desirable. Currently the Taiwanese Romanization class instances are mutable. Normalization changes internal representation instead of returning a new immutable object. In addition, for the libraries to be useful for building language-related web applications, bindings to major scripting languages are also desirable. These are the things that developers interested in the field can work on.

I’ll be highly interested in hearing from you if you use or plan to use Formosana in your own projects. My contact info regarding to this project can be found on my github profile.

Photo

Fri, 16 Apr 2010 19:31:17 +0800

Jamreilly: Lewis Thomas on the etymology of etymology

Sat, 03 Apr 2010 23:26:43 +0800

Jamreilly: Lewis Thomas on the etymology of etymology:

The connection of soothe to yes is strange but true; it takes a bit of relaxing to get it straight in the mind. I suppose that if something is, and is true, and leads to nodding of the head, and brings the archaic response sooth, or the modern answer yes, it is a soothing experience. The truth is not always soothing, but in a better world it ought to be.

New Work: LadyBugz, a FogBugz Client for Mac

Fri, 26 Mar 2010 22:53:00 +0800

I’m happy that my company just released the version 1.0 of LadyBugz, a FogBugz client for Mac.

If you just heard FogBugz for the first time, it is a “bug and issue tracking, project management, help desk software” service. FogBugz is a product of FogCreek, one of whose founders is Joel Spolsky, the software luminary behind Joel on Software and Stack Overflow.

What Zonble and I like about FogBugz is that it fits the needs of a software company well. The nature of our work requires a good issue tracking tool, but we also need to communicate with clients and customers. Many issue tracking tools are not designed with support department in mind, and this is where FogBugz does it just right.

As we used FogBugz more and more, it became natural that we wanted to create a native Mac client for it. It’s interesting that many good Mac and iPhone applications these days are client software to well established services. Tweetie is a good example. We also happened to know one thing or two about working with successful web services. So we decided to create a Mac client to FogBugz that we want to have the best of the two worlds: good web service delivered with a fast native interface.

The version 1.0 of LadyBugz gives users an integrated case and event browser, a case editor, and a mail composer. Those three components correspond to the three areas in which FogBugz excels: project management, bug and issue tracking, and help desk / customer service integration. It also comes with snippet support, an important feature for people who do frontline support services. Good help desk features are what make FogBugz stand out among similar services, and we would also like to design LadyBugz with both engineering and support departments in mind.

We had the first beta version up and running in mid-November last year, and since then we used it every day for our project management and product support. Like many applications with ambitious feature sets, LadyBugz also underwent architectural changes and total rewrites. We’ve also decided to target solely on the latest Mac OS X (10.6) so that we can leverage great tools like Grand Central Dispatch-backed NSOperationQueue, blocks, and many user interface improvements. The aim is to create smooth user experience with good technical performances.

Since this is our first full-featured Mac application, and also our first commercial product developed as an independent software vendor, we really hope LadyBugz brings good value to FogBugz users. And just like any version 1.0 software, this is really just the beginning of many great plans ahead. We want to spread the words, and will continue bringing out great things to our users.

Finally, I’d like to thank Mike Ash, Jeff Johnson and Lee Falin of Rogue Amoeba, Joe Goh of Phone Journal, Pierre Bernard of Houdah Software, Justin Williams of Second Gear, and Evadne Wu of Iridia Productions for having given us many suggestions that shaped the application. I’d also like to express my gratitude to the authors of the open source libraries that we use, including Sparkle and many others—they are a major force that makes the Mac developer community strong and vibrant.

LadyBugz is commercial software, with an individual license for US$55. You can download and try it with full features for free for 21 days. It also has a presence on Twitter, so follow us and let us know how we do.

Thanks!

LLVM Wallpaper and OS X's xattr

Tue, 23 Mar 2010 01:26:00 +0800

For the past few months I’ve been using this as my wallpaper/desktop background. I’m seldom a fan of any personality or any project, but hey it’s LLVM.

I finally found out the source of the picture. It’s made by putting the LLVM logo over one of Cocoia’s wallpapers.

How did I find out the source? I must have seen the link from some friend’s twitter long time ago, but the friend’s tweets are locked, and Twitter’s search is not really helpful.

So how did I finally find out? Surprisingly, via Get Info in Finder! Essentially, it’s the xattr (extended attributes) in the file. Since 10.5, all files downloaded by Safari carry an xattr called com.apple.metadata:kMDItemWhereFroms:. You can use the command line tool xattr to inspect those attributes. The attribute values are in the form of property lists.

I find this a good point to show the importance of file system advance and why metadata matters.

The Afterbuzz

Tue, 16 Feb 2010 18:28:11 +0800

Jacqui Cheng of ars technica, my emphasis:

These swift and widespread changes to Buzz’s automatic-everything behaviors are certainly commendable, and it’s clear that Google does listen to user feedback in ways that other companies don’t. However, the sheer extent to which the company had to back off from its initial launch functionality goes to show how delusional Google was when it came to its assumptions about user privacy.

Just because I share something somewhere else on the Internet doesn’t mean I want it auto-linked to something else I use, and just because I choose to use Gmail doesn’t mean I even necessarily want to be involved in Buzz at all. Those should be choices that are left up to the user, not Google on behalf of the user. End result: Google is left cleaning up its messes when it could be moving forward.

Reblog: A conversation Dan Wineman has every month or so

Mon, 15 Feb 2010 10:05:00 +0800

mrgan:

Even if Flash were the world’s best-engineered animation and interaction technology (which, lol, it’s not) scorn would be heaped on it for what it has allowed people to do to restaurant websites.

That said, I recommend that you write a nice email to your local Flash-webbed business and suggest to them, as nicely as you can, that they offer a one-page summary of what you need to know: hours, location, menu if possible. My favorite restaurant in the world has an eye-gouging website which nevertheless tells you all you need to know in the first three seconds of browsing.

I can’t agree more. So many times I had to pick a random place to eat because the one I wanted to go had, darn, a Flash-only website. Flash is even more entrenched in Taiwan because business owners find it flashy, and flashy things mean they’re getting the money’s worth.

What restaurant owners don’t realize is Flash-only websites actually hurt their business. Responsible designers should remind their clients that. Although I’d say the exact opposite is at work here. It’s the incentive thing.

Imagine If Your Bank Did That to You...

Mon, 15 Feb 2010 02:36:00 +0800

This is from the leader article, “Who’s Afarid of Google?”, of The Economist, August 30, 2007, my emphasis:

Google is often compared to Microsoft (another enemy, incidentally); but its evolution is actually closer to that of the banking industry. Just as financial institutions grew to become repositories of people’s money, and thus guardians of private information about their finances, Google is now turning into a custodian of a far wider and more intimate range of information about individuals. […]

[…] That said, conflicts of interest will become inevitable—especially with privacy.

[…] The answer, as with banks in the past, must lie somewhere in the middle; and the right point for the dial is likely to change, as circumstances change. That will be the main public interest in Google. […]

One obvious strategy is to allay concerns over Google’s trustworthiness by becoming more transparent and opening up more of its processes and plans to scrutiny. But it also needs a deeper change of heart. Pretending that, just because your founders are nice young men and you give away lots of services, society has no right to question your motives no longer seems sensible. Google is a capitalist tool—and a useful one. Better, surely, to face the coming storm on that foundation, than on a trite slogan that could be your undoing.

I think many of us in the tech industry, who are supposed to know better, are actually confused about the multiple definitions of the term “openness”. Promoting open source technology and openness in tech standards is usually a good thing. Crossing the border to make your life open, without qualification, prior notice or warning, is not. Imagine if your bank did what Google Buzz did to you, making your account history open and trackable by others (say, those you recently wired money to, or received wires from), what your reaction would be? I’d say the bank would be in big trouble.

Google has improved Buzz’s privacy settings for the past few days. Still, there are questions on how the whole thing happened at all. I’m also troubled by the fact that Google’s PR machine doesn’t sound a bit apologetic—so the inconveniences and confusions (to say the least) that many users had endured for the past few days were whitewashed.

Counternotions, a blog that often raises sharp questions on big players’ strategies, comments:

Yes, someone at Google […] thought it was alright AND excellent business practice to graft Buzz over Gmail simply for expediency. Now, we hear they may separate the two. But not only the damage is done, but we also know that there’s not enough deep thinking about and appreciation of the customer experience at all at Google. It’s naive beyond belief, for a $150B company.

If a company starts to think it’s beyond reproach and its customers accept whatever new thing it gives them, it’s a bad sign indeed.

Thank You, Google, for Wasting One Hour of My Precious Working Time Rescuing My Friends' and My Privacy, for Making Me Unable to Sleep Well from Now On.

Fri, 12 Feb 2010 04:43:00 +0800

As I said in a previous post, I turned off Google Buzz immediately when it was enabled onto my gmail account. I was annoyed by the fact that I was not asked to opt in, shocked by the fact that many of my email contacts were automatically added in, and deeply troubled by the fact that, from a quick glance, I have absolutely no control over the whole thing: access control and privacy level settings.

I turned off Buzz by clicking on the very small text link at the very bottom of my gmail page. Who would have thought that it is put in the very sheepish place where privacy policy and other legal prints are? And that’s not even the end of the story.

A few friends have reported that many of your online traces are still there even if you turned off Buzz. I had a hunch that it was going to be bad. So I re-enabled Buzz and did some experiments with other friends. It was worse.

A quick summary of a few very troubling facts.

People can see who you are inadvertently following. That mostly includes contacts you’ve recently writing to. Good luck if you were writing to an old flame, to a competitor, to a potential client that asks to remain confidential, or to a potential new employer.
You’re inadvertently added to people’s follow list. And you have absolutely no control over who can see you and who can add you.
People can see who you’re inadvertently following and who are inadvertently following you.
Blocking people takes you away from people’s follow list. If I block Alice, I’m now gone from Alice’s follower list. So when Bob looks at Alice’s follower list, he won’t see me. But,
You have to re-enable Buzz to block people. If you don’t block people, they’ll stay on your follower list forever.
Even if you have turned off Buzz, people are still able to find you—and as a result are able to comb through your “social network”—through other people’s follower/following lists. I’ve heard that if you have ever created a Google Profile, or is sharing your Google Reader feeds to Buzz, the situation is worse.
If someone disabled Buzz, you can’t block them. Because there is no longer a profile link for you to click into, and that’s the only place to unfollow people. And they’ll stay in your “following you” list forever.

Confusing? I’m as confused as you are.

The damage is already done. Evgeny Morozov of Foreign Policy has written on the political ramification of Google’s careless rollout of Buzz, especially in oppressive countries.

What deeply troubled me is that I had to learn about how Buzz worked in order to thwart potential invasions to my privacy, over which I used to think I’ve had good control with Google’s trusted mail service. And now I start to worry, even start to fret if I have missed anything to plug the holes.

I had spent an hour unfollowing everyone that I was “following” and blocking everyone that Buzz said was followed me. I assume this is for now the only way to keep my friends and I from the mess.

But now I know I won’t sleep well and have to come back to check (by re-enabling Buzz then turning it off again) to see if I’ve missing anything, or if another place catches on fire, another item of my private information was inadvertently leaked. And the entire world might still think if such information is revealed with my consent and authorization.

"Because in the business also known as social network, he who asketh not users’ consent, careth..."

Thu, 11 Feb 2010 13:55:00 +0800

“Because in the business also known as social network, he who asketh not users’ consent, careth not if they resent.”

- My reply to a friend’s comment on my tweet that I turned off Google Buzz. She asked, “Why can’t the world be simpler?” Above was my thought.

Social Network and Email Don't Go Together

Thu, 11 Feb 2010 13:37:00 +0800

I turned off Google Buzz the moment I saw its advertisement blocking my gmail page. And I had to google it to learn how to turn it off. And I thought only Yahoo! and Microsoft did stupid things when it comes to email.

People, your email is not your social network. Just because you own a phone number, that doesn’t mean you have to invite everyone you ever called to call you to say hello, nor does it mean you are interested in hearing other people’s calls. The worst thing is, what Google Buzz is doing is to equivalent to publishing the names of a few dozens of people you’ve recently called to the entire world.

A few weeks ago, I logged into my long deserted Yahoo! email account to see if there was still anyone I knew emailing to that abandoned address. I used to do that every few months. To my horror, I discovered I was enrolled in many social networks I didn’t care about without my prior consent. I could even saw updates (equally inadvertent) from some contacts that I really only contacted once in like… what, 10 years ago? I immediately cancelled my already disused Yahoo! email for good. Microsoft does similiar things if you happen to use both its whatsitsname Messenger and its Live Mail.

Google’s email used to work for me very well because that was the only service that didn’t try to be a sucker. For all its good reputation on thwarting email spam, this is the biggest surprise I’ve had from them yet.

Update: What annoyed me was how Buzz was deployed. It was opt-out by default, not opt-in. I can understand the rationale Google wants to do this. Books like Nudge show opt-in and opt-out can make huge differences. Also, the nature of web app means new features are enabled automatically to everyone. The problem lies in the fact inadvertently joined social network can disrupt your ongoing design to compartmentalize your communication channels.