My Korean Blog

I've decided to use my Vox blog
as my Korean language blog. Although my sense of humor seems language independent, my mode of thinking and attitude differs quite a bit in Korean language, so do check it out if you can read Korean.

Powerset and Pipes

Off the hip morning coffee commentary on two freshest hypes.
Powerset: It is difficult to figure out why behind questions. And people often make mistakes in forming their questions. In the end, I think Powerset search results will disappoint and Powerset users will end up typing in keywords. If their target market is occasional computer users, they have to be the default search engine on new computers, but I doubt they have the financial means to make that happen.
Pipes: I had a similar idea awhile back for which got the feedcrew.com domain. I stopped working on it when I realized the core problem which FeedCrew, Pipes, and Ning shares: success will lead to failure, meaning popular pipes will be cloned elsewhere with better tailor-fitted user experience and hand-coded performance. In the end, pipes will become too much of a resource drain to continue and Yahoo will have to shut the service down. Another case of reality tormenting geeky ideals.

Wikithon Afterthought

Wikithon was an interesting experience, interesting like unconference. It could have been better with a bit more organization though.
I had no idea when it was supposed to start. Apparently it was something everyone knew but I somehow didn't. When I got there, closer to afternoon than morning, a little over 20 people were sitting against the walls (kinda reminded me of prom night), talking quietly with each other and tapping on their laptops busily but only occasionally looking up. All the chairs were at the enter of the room but not occupied.
I was expecting some coordination effort in the afternoon but everyone was kept busy tapping, whispering, coming, and going all afternoon. I could have used some help from someone knowledgeable about Socialtext open source wiki (aka STOSS) so I could get my thingy (identicon wiki-integration) done quickly. But no one asked and I didn't speakup, so I wasted most of my time on trying to install STOSS and requirements on my laptop. It would have been better if someone went around every hour  or so checking in on everyone.
At around 7pm, activity finally picked up and 6-7 people/team presented the result of their projects. They were all interesting but more participation from non-Socialtext developers is needed. This will improve in the future because Wikithon will apparently become a monthly event.
Anyway, I didn't do much except chat with folks. I could have done more or filled in where I saw shortcomings but…well, I didn't. Why not? Because I felt the event was more of a Socialtext thing than something anyone off the street can take control and run with. A little younger and more reckless me would have though. Another side-effect of growing old, I guess. Sometimes a loud mouth gregarious clown is desperately needed because, overall, Wikithon felt too polite and too respectful despite all the free-spirit settings, like hippies sitting on a church bench.
I hope I didn't piss off all the particpants with this post. My intention is to improve the event, not trash it. I hope wider variety of folks participate in the future and turn it into a centerpiece event for the wiki community.

Tags: , ,

SiteKey Ineffective?

News.com reports that a joint study by four Harvard and MIT researchers claims that SiteKey (aka PassMark) is ineffective. Ouch. While I have little doubts about their integrity, I do wonder if the study is not flawed. For example, doesn't using people who willingly let others observe them signing into their bank account for such a study skew the result? It's probably not as bad as counting virgins among prostitutes but I would like to hear more about how they accounted for such problems.
To be frank, I don't think we ever did a formal study like they did. Why? First, time. Second, money. Third, lack of deathwish. I mean, that's like stopping by the hospital before going to the prom to see if you have a fatal disease, isn't it?  Fourth, user experience (image and questions) was only a part of the PassMark story.

Update:

This news apparently made some people curious enough to do some ad hoc experiments using their own bank accounts. That's a bad idea, folks. If your behavior stray outside your normal user behavior pattern, you are inviting future inconveniences at best.

Wikithon and Identicon

I'll be participating in the Wikithon next Wednesday at Socialtext's new office. My goal is to help people add identicon support to their wikis. If you are interested, join me at the Wikithon. Heck, even if it's not wiki-related, come on down and let's talk about your identicon application. Personally, I would like to see them in IMs and IRCs.
Adding identicon support to WikiCalc/SocialCalc will be interesting too since it is difficult to tell what each numbers in cells represent without looking at the column and row headers. One idea is to auto-assign each column and row labels then display them in cells on mouseover. So the number 512 is in Electricity column and January row, moving the mouse over the number would display identicon for Electricity and January.
I am working on another wiki-related idea which I might be able to show at Wikithon. All I can say for now is that it'll open up a whole new world for wiki users, not unlike the way WikiCalc does.

Canvas Element Issues

Implementing identicon using canvas uncovered some issues relevant to developers. I'll list them here for discussion:
No Data
Storing data used to render into a canvas directly in canvas is a common use case IMHO. With identicon, I am using the 'title' attribute on canvas element to store the identicon code but it would be nice to have an attribute for this purpose ('data'?).
No Script
Since canvas can't be drawn into unless javascript is enabled, canvas support should be disabled if javascript is disabled. As it is now, fallback doesn't kick in and canvas area appears blank.
Spaced Out
I worked around the No Script issue by wrapping a fallback image inside a 'noscript' element but, since the blank canvas takes up space, both will show next to each other when script is turned off, screwing up layout. While CSS tricks can be used to overlap them, I think unnecessary complications should be avoided if possible.
Active Fallback Unnecessary Get

Firefox fetches resources referenced from canvas fallback content even when canvas is working. My expectation is that it shouldn't do this because, when large number of canvases are used in a page and each had fallback content, page would load very slowly.

Canvas Identicon Deployed

I just deployed the latest version of Daily which uses canvas-based implementation of Identicon. If you use a browser with Canvas element support (Firefox 1.5+, Safari 2.0+, Opera 9.0+), take a look at some of my posts with comments (including the one that started the avalanche if you want to see the rare sight of 400+ canvas elements being rendered on the fly). You'll notice that identicons look much smoother looking now. On IE, it looks the same. I could have used excanvas but I didn't feel it was stable enough.
One thing that puzzles me though is that Firefox 2.0 seems to fetch the URL of image element inside the canvas element when I was expecting that to happen only when canvas support is not available (i.e. no canvas support or when scripting is off). That hurts, particularly for monstrous posts with hundreds of identicons. Currently, I am detecting only problematic canvas support (Safari 2.0) to generate canvas tag without image element within it but it looks like I'll have to do more to emit only the canvas tag if I am going to avoid unnecessary image requests.
Anyway, let me know if you run into any problems seeing identicons. Meanwhile, I am going to spend some quality time with the Identitune idea.
Update:
Apparently, identicons are not rendered on javascript-disabled Firefox browsers because canvas support is not disabled when script is disabled. They should spell out expected behavior in the canvas spec. While at it, an attribute for specifying data is needed. For now, I am using title attribute but that feels wrong.
Update 2:
Fixed noscript/canvas issue by adding img version inside noscript tag. Fixed unnecessary img URL fetch in Firefox by skipping fallback img tag inside the canvas tag (this speeds up canvas version load lightening fast, even with 400+ identicons in a page!). I think canvas support in browsers needs to workout these common issues.