Saturday, January 31, 2009

How to Alienate a Community 101: The "Gurus" Program

About a year ago, it was decided that we'd pilot a "gurus" program in various API support forums, including my own Google Maps API forum. We would declare a small number of developers to be the gurus in the forum and give them a title next to their nickname. We hoped that it would be a good thing for the gurus in terms of resume/reputation building, a good thing for newbies in the group in that they'd know who the most prolific posters were, and a good thing for us as it might encourage the gurus to post more, and perhaps contribute in other ways (articles/blog posts). So, I analyzed my forum, selected 4 developers that consistently and constantly delivered helpful posts, informed them over email, and then posted an announcement in the forum about it. Bad idea.

About 15 un-happy developers replied to the post, and their concerns all boiled down to one basic issue. I had created a black&white situation where there was formerly a wide spectrum. The Maps API has been around for a while now, and so there are quite a few developers that are familiar with it enough to answer some of the questions posed in the group, and hell, there are also quite a few expert developers as well. By designating only 4 developers as the one and true "Gurus", I had shoved all the people near the top to the other end of the spectrum, and they rightfully didn't feel they belonged there. They were worried that people seeking freelance developers would disregard them due to lack of the "Guru" title, and that newbies asking questions in the group wouldn't value their responses as much - and, to be honest, they were also offended by the implication in my announcement that some developers weren't as trustworthy as others. After realizing that I'd lost the trust of many top members of my community (and possibly their participation), but also deciding I didn't want to strip those top 4 posters of their well-earned title, we kept the "Guru" designation around but reduced the messaging around it.

The gurus program, atleast in the form I executed it, was a failure. The only positive aspects of it was that it gave me a way to formally thank my top posters for their hard work, and it gives me an excuse to email only that group when I want to discuss a Maps API issue with a small group ("Dear gurus.."). But the negative aspect - alienating the rest of the community - outweighed the positive. I do think the program could have worked if:

  • The Maps API community was 99.9% newbies and .1% experts, and I nominated all of the .1% as gurus. This is what happened in the AJAX APIs group, and it worked great because that 99.9% felt incredibly indebted and in awe of the 1 guru.
  • OR
  • There were multiple levels of titles, and designation was done automatically. This is how many bulletin boards operate, and every message is coupled with stats about a poster: nickname, designation, number of posts, date joined, etc. There is a way to view most of this information in Groups (except an automated title), but it requires clicking on a person's name, and very few people do that.
  • OR
  • The gurus program was a designation acknowledged privately, and not paraded around in the main forum. This would be a similar concept to having a private beta testers group. The people in the group feel good that they're in this elite group, and other people don't feel bad that they're not in it - since they're not aware it exists, or at the very least, it's not shoved in their faces.

Generally, I learned that it's a tricky thing to single out and award a small group of people in a community where the participation levels are so distributed, and that it has the effect of de-motivating the rest of the community to participate. I'd be interested to hear how this relates to other communities on the web, and what experiences others have had.

Thursday, January 22, 2009

HTML5 vs. Flex for RIAs (Ignite Style!)

Yesterday, I gave a talk about HTML5/Flex at Ignite Sydney. I signed up for the talk both because I wanted an excuse to research HTML5 more and because the format seemed like a challenge. Each person gets 5 minutes, 20 slides, 15 seconds each, with no leeway at all. It means that you have to be able to squeeze what you want to say in 15 seconds, but not squeeze too hard as you'll be left with an awkward 2 seconds of silence (trust me, 2 seconds is still awkward!). I prepared more for this 5 minute talk than I've prepared for any talk before, including spending 2 days researching Flex and HTML5, and a day sneaking in and out of conference rooms to rehearse my talk.

Anyway, in the end, it was a great experience, and I only messed up the final 5 words of the talk (end strong, oops). The other speakers were also awesome, particularly Kieran's talk about failures, Jason's talk about lean programming (with lots of stick figures), and MayMay's talk about gender and technology. I'm looking forward to seeing the talks at the next Ignite Sydney in May, and not having to be one of the damn-nerve-wracked speakers at it. :)

The slides are embedded below, and there'll be a Youtube video up in a few days. Since my talk involved alot of pre-research, I figured it'd be useful to list links relevant to each slides below. I hope this talk inspires others to research these technologies more, and for those interested in seeing HTML5 grow (or change), I encourage you to contribute to the WHATWG HTML5 mailing lists.. or just follow them on twitter! (@whatwg).

  • Intro:
    Flex & AJAX: Friends or Foes?, Slideshare: RIA Meets Desktop, Slideshare: Flash, Flex, AIR: A Brief Survey
  • RIA
  • HTML5: HTML5 Spec, ESW Wiki: History of HTML, History of HTML
  • Flex: Wikipedia: Adobe Flex, Wikipedia: Adobe Flash Player
  • Openness: Flex: Open Source, Adobe, Mozilla, and Tamarin, Tamarin, WHATWG
  • UI Widgets: Flex 3 Style Explorer, HTML5 Spec: The DataGrid Element,
    HTML5 Spec: The Menu Element
  • Forms: Flex 3 Style Explorer, Flex Quickstart: Validating Data, Flex Reference: Validators, HTML5 Spec: The Input Element, HTML5 Spec: Email state, HTML5 Spec: Form Constraints
  • Vector Graphics: Flex Reference: Graphics, Mandelbrot Flash Map, Mozilla: Canvas Tutorial, HTML5 Spec: The Canvas Element, Rendering Polygons with Canvas
  • 3D Graphics: Flash Player 10 Features 3D Support, Flex Reference: Matrix3d, Taking the Canvas to Another Dimension ,PaperVision3D ,Flash 3D Spider ,HTML5 Spec: The Canvas Element ,All together now: Video, 3D, File access
  • Bitmap Manipulation: Slideshare: Bitmap Manipulation with Flash ,Flex Graphics Tricks: Part 3 ,HTML5 Spec: The Canvas Element ,Flex Reference: BitmapData ,Demo: GPS Map in Canvas ,Pixel-based Manipulation in Canvas
  • Video: Flex Reference: VideoDisplay ,Demo: VideoDisplay in 3D ,FLV Format ,HTML5 Spec: The video element ,A call for video on the web - Opera
  • History: Using the HistoryManager ,Back & Forth: Custom History Management with Flex ,Flex Reference: HistoryManager ,HTML5 Spec: The History Interface ,HTML5 Spec: Undo History
  • Persistent Connections: Flex Reference: Socket ,Google Maps Collaboration Using Google's New ActionScript API + BlazeDS ,HTML5 Spec: Web Sockets
  • Drag + Drop: Flex Reference: Clipboard ,Drag+Drop in Flash ,MapClipboard Demo: Source Code ,Simple Drag&Drop in AIR ,HTML5 Element: Drag & Drop
  • File System: ,AIR: Local File System ,Upload input type ,HTML5 Spec: localStorage
  • Offline Access: Unlocking the AIR API ,Monitoring Network Activity ,HTML5 Spec: Offline Web Applications
  • Compatibility: Flash Player Penetration ,Browser Wars
  • Testing: ASUnit ,Fluint ,JSUnit ,Selenium ,Watir ,WebDriver
  • Who wins?