Dealing with an Unhappy Community

Most of us deal with the “community” in our jobs on some level or another. Perhaps we are an engineer on a product that has a community of users, or work for a company that has a community of customers, or, perhaps, are in a position to be part of the public face of a company, product or service who is tasked with communicating with the community as part of your job duties. Recently, I wrote an article about a bit of a dust up in the AngularJS community about the plans for Angular 2.0 and it got me thinking about how we deal with the community - specifically when there is a widespread community backlash. We’re Not Talking About Trolls There’s a big difference between trolls, whose complaints are almost always singular in nature (and agressive in tone). In my experience, trolls complain alone and specifically target an issue that is very specific to them. In this case, I’m talking about a decision that caused widespread unhappiness in your customer base or users and is being expressed, sometimes angrily but rarely aggressively, by a large swath of your community. I Have Some Experience in This I’ve been on both sides of community backlashes. Professionally, I was the Flash and Flex community manager at Adobe around the time of the infamous “Thoughts on Flash” essay by Steve Jobs. At the time and understandably, any actions Adobe took around Flash and Flex were heavily scrutinized. I was still a public face for the products (even if I had technically just been reorged) around the time that Adobe decided to end of life…errr…open source Flex. As you can imagine, I caught a fair share of flak. Nonetheless, I think it taught me a lot of great lessons that I’ve carried into my positions since, both for and after Adobe. The Different Kinds of Decisions that Cause Backlash In my experience there are three core types of decisions (by a product team, company, open source project, etc.) that can often lead to a backlash. The first two are relatively easy to handle. Necessary Decisions Let’s face it - sometimes there are decisions that you, your company, or your product team may make that simply have to be made, but will, nonetheless, make your community unhappy. Sometimes, you, personally, don’t even like the decision. However, there’s a big difference betwen liking a decision and understanding and supporting why it was made. To me this is easy to handle as your options are very limited. You can and should be understanding of your communities right to be upset about the decision. You can communicate why the decision was necessary and, if applicable, explain that you aren’t happy either, even if you support its necessity. The last thing you can do in this case is simply develop a thick skin. You’re gonna get some lumps and that’s ok. Keep in mind that these things pass and often seem much worse in the moment than they do in retrospect. Poorly Communicated Decisions Sometimes it isn’t really what changed that upset your community but how you, your company or others communicated that decision to them. In my experience, sometimes companies spend so much time wordsmithing their communications that they remove all humanity from them - they sound like they are coming from a committee who is more concerned with protecting the company than with the impact of decisions on their customers. This (and other things) can lead to communicating a the impact of a change poorly. In this case, I also think the response is simple, if not easy, which is to clear up the miscommunication (and soften any hard feelings it may have caused). For instance, you could draft a clear and personal message expressing concern for the misunderstanding and clarifying the impact. Make this the opposite of the company-type PR response - make sure they understand that you are a part of that community and care personally about it. Of course, if you can smooth some hurt feelings with free stuff of some sort, that always helps too. “Best Intention” Decisions What the heck do I mean by this? Well, this is kind of where AngularJS was. Sometimes decisions are made that impact our customers, users, or whatever that are made with the best intentions, but, in the end, we misread the needs of our customers/users/etc. It wasn’t that we miscommunicated. They understood - they just didn’t like what they heard. You may think these would actually be the easiest decisions to deal with - simply walk back the choice that made them unhappy. However, assuming this is the best response isn’t correct. Sometimes, as it turns out, the decision you made is the right decision for the future of the product, service, company, etc. This can get lost in the fog of loud and unhappy users. However, if you let the dust settle, it turns out that it wasn’t as big a deal as it sounded and the “mob” seemed much larger because it was loud. Sometimes, the decision was in the right direction, but it’s now up to you to translate your customer anger into adjustments to the choice (this appears to be what AngularJS is doing by the way). You were headed down the right path, you just went a little too far or veered slightly off course. Now you just need to take a few steps back or to the right/left, and your community will be happy again. Sometimes, the decision was a poor one made with the best of intentions and should, in fact, be walked back entirely. The point is, there are many options to choose from in this case, and knowing which is the right one isn’t always easy when you are receiving a barrage of unhappy tweets, blog posts, comments and more coming your way. Whatever You Do, Don’t Assume Your Community Is Wrong Here’s the thing to recognize - in none of these cases is the community wrong. Remember, these aren’t trolls - they are community members we care about with a legitimate complaint. In case 1, they have every right to be unhappy even if there’s little we can do about it. In case 2, we communicated poorly and this led to them being unhappy. In case 3, we probably just need to adjust a little - even if the reaction may have seemed overly harsh. The single biggest mistake you can make in any of these cases is thinking you are somehow better or more enlightened than your commmunity and plowing ahead with your decisions accordingly. I’d love to hear thoughts.

Posted by on 3 November 2014 | 3:00 am

Boston Festival of Indie Games 2014

This past weekend I had the pleasure of attending the latest Boston Festival of Indie Games at MIT. This was the third year of the event and my second attending. This year, as last, I attended with my two boys (ages 8 and 12). Here are some thoughts on the event and some of the games that I, personally, found interesting. The Venue This year, as last, the event was held in the athletic center at MIT. However, the event outgrew the downstairs room that it was held in last year and actually took up both floors - the table top games were downstairs and the digital games upstairs (sessions were elsewhere but I didn’t attend any). While I am happy that the event has grown (and plenty happy to pay the small $10 fee to attend), it did come with a major drawback: the upstairs room was hot and humid - uncomfortably so. This even on a day when Boston itself was unusually cool for mid-September. Honestly, we might have spent more time there if it weren’t for the unpleasant conditions. My Favorite Games Here are my favorites from what I was able to try at the showcase. Bōru mo This was probably my favorite game of the day. It’s a fun 2 to 4 player game where the point of the game is to jump on the other players until they run out of lives and, hopefully, you are the last one standing. The way you do this is that your little creature turns into a ball when he jumps and can smash the opponent. It sounds simple but is harder than you’d think. The multi-level platforms and a variety of power-ups adds some extra fun to the game, which, as I understand it, will be PC only for the moment with other platforms hopefully soon. One of the best aspects of this game is the design. It’s colorful and cute, which somehow adds to the sense of fun. This shouldn’t come as a huge surprise given that the developer is a graphic designer during his day job and this was built over nights and weekends. Shock Jocks This is a clever iPad game from @BigMikeTheDev. It’s basically a two-player “air hockey” with a bit of a twist. Your paddle is electric and needs to maintain a charge. Every time you bounce the ball back, depending on a number of factors, it eats into your charge. The strategy is keeping your paddles charged (by placing your fingers along the sides of the game board) but not missing the shot. There’s no site just yet, so follow @BigMikeTheDev for updates. Swimsanity A Kickstarter project being developed by Decoy Games, Swimsantity is a 4 player underwater brawler with a variety of game modes. Each player comes with different weapons and different abilities, the later of which charge up as you compete. In one game mode, it was simply a Super Smash Brothers type brawl with the winner being the one who gets knocked out the least. In the latter, it was a cooperative mode where you needed to help each other to get through the level without being caught by the creature following your team. The artwork and controls were all nicely done and my boys and I enjoyed playing together. World Zombination World Zombination Teaser Trailer from Proletariat Inc on Vimeo. Yes, the zombie thing is getting old, as made clear by the number of zombie games even at this festival, but this one from Proletariat stood out. There are two modes. In one you control the heroes trying to defend cities against the hordes of zombies. This mode works much like a tower defense game. In the other (and the mode I got to play), you are the zombie hordes trying to destroy the city. In this mode, you use different “mutations” to give members of your zombie horde different powers. Some powers work better than others to defeat certain heroes (for instance, a stealth zombie is good against the snipers). While both modes are takes on existing games, the combination of the two modes, along with nice artwork and easy to understand gameplay, made this one a winner in my mind.

Posted by on 16 September 2014 | 4:00 am

Running Great Technical Conferences

As some readers may know, for five years I ran a small (about 350 people) conference here in Boston. Originally called Flex Camp Boston (and obviously focused on Flex), it was renamed RIA Unleashed and subsequently Web Unleashed. The event still exists, run by FITC and occurring this September in Toronto. I loved running this event, and generally enjoy running events overall. This is why I was interested in reading How To Plan And Run A Great Conference Experience by Zach Inglis. It’s a very good article and you should definitely read it if you have interest in the topic. However, I had several points I thought needed adding and one I disagreed with. Much of this was mentioned in my comment there but not I’ve edited it and amended it a bit. On paying speakers - One complication I came across (at least for US based conferences) was paying international speakers. There may be legal/tax laws that complicate paying international speakers (especially over certain dollar amounts), and this may vary from country to country, depending on where you are running your event. I don’t know the specifics but it’s worth noting. Promotion - In my experience, getting the word out was the hardest part of running any event. It’s common for first time organizers to think they can rely on high profile speakers to get out and promote your event, but they are usually mistaken (nothing against the speakers as I’ve been one many times). Promoting the event required a lot of research on things like relevant user groups or mailing lists and the use of targeted discounts (I used codes) to figure out which avenues worked best and double-down on them. WiFi, WiFi, WiFi - It’s so hard to get this right (because you are often at the mercy of the venue or vendors) but so important for a technical conference. Complaining about WiFi at tech conferences is like complaining about the weather, everyone does it from time to time. It never seems to be perfect, but pay close attention to this as it can really ruin the experience if your WiFi is unusable by a large portion of your audience. Expect to lose money? - The author states that you should and it is the one area I disagree with. I nailed down sponsors to cover the guaranteed costs from day one - before the conference was even announced. I learned quickly (an;d through trial and error) where you can cut costs and minimize risk. Things like find out what the minimum guarantees are to secure your preferred venue and only guarantee that (they can always up food or other expenses but they will never lower them once you sign); and plan on a range of 10-20% no shows (regardless of how much you charge - for free events this is much higher) and plan food and swag accordingly (you’ll learn your percentage range over time and this can be useful even to carefully oversell seats, which can really improve profitability). The point is, with careful planning, this doesn’t have to be a money loser. I always had the expectation that I would not make money but I also was not going to lose money (not including time spent, obviously). Organizers who lose money are less likely to run the event again, which, in and of itself, does a disservice to their attendees. Be prepared to be scared - My first year I sold out quickly. However, this is not necessarily the norm (and wasn’t in subsequent years). In fact, a majority of tickets will be sold during the last 2-3 weeks. A month before, you may be scared out of your mind that the event will be a failure only to find that you sold out or hit your targets in the end. This became a pattern every year after the first and is something I have confirmed with many conference organizers. However, you cannot be reactive, relying on last minute promotions to salvage things. Start any big promotional push early enough that it can have an impact in those final two weeks because, most likely, any promotion you start in the last two weeks doesn’t have enough time to get the traction it needs to succeed. (A side note on this topic, it seems that many people make the decision to attend early but wait until the last minute to make purchases - I’ve done this many times myself, and can explain why last minute promotions don’t have a great impact). If you’ve run an event and have tips and opinions to share, I encourage you to comment on the article.

Posted by on 16 August 2014 | 4:00 am

The Best Features in ECMAScript 6?

Recently I had the chance to attend QCon NY. Actually, I was fortunate enough to be on the programming committee and to lead a track there. My track was called “Beyond JavaScript” and one of my featured speakers was Dr. Axel Rauchsmayer speaking on ECMAScript 6 (i.e. the next version of JavaScript). I was very excited that Axel was able to attend all the way from Munich, as he is well known expert on ES6 (and author of the new book “Speaking JavaScript”). During my time at the conference I was able to interview Axel. We mostly discussed the process whereby new features are added to the ES6 spec, using JavaScript for enterprise development and which features Axel is most excited about in ES6. So what two features did Axel choose as his favorites in ES6? I think you may be surprised, but you’ll have to watch or read the interview on InfoQ to find out.

Posted by on 23 July 2014 | 6:12 am

Comparing Static Site Engines

As part of researching for restarting this blog as well as for my work developing the Telerik Developer Network, I researched several of the most well-known static site engines. Specifically, I tried to build this site using Jekyll (which is what I ended up using), Harp and Roots. These were the three engines listed prominently on the resource site. I really think that many sites, especially those focused purely on content, can potentially move away from dynamic, CMS-driven site architectures that can be a burden to maintain, to purely static HTML with a “back-end” that generates the site locally. I wrote up my experiences and review of each for the Telerik Developer Network in an article entitled “Static Site Engines Battle Royale”. If you are interested in static engines, are considering a move or are just curious what the whole thing is about, check it out.

Posted by on 22 July 2014 | 6:15 am

Starting Anew

Almost 10 years ago, on January 1, 2005, I started a blog called Remote Synthesis. The name came from synonyms for “Cold” and “Fusion” as ColdFusion development was my primary focus back then. A lot has happened in 10 years. The blog gained a good deal of popularity during the years that I was working on my popular ColdFusion code generator and posting the ColdFusion Open Source List. It remained somewhat popular during my years working with Flex and running the Flex Camp Boston conference (later RIA Unleashed and now Web Unleashed). Eventually, when joining Adobe, my focus started to drift from that blog to publishing elsewhere - on the Adobe Developer Connection that I was helping to run and other writing responsibilities. In 2013, I started a site called Flippin’ Awesome (now part of The Modern Web). While it included the contributions of many authors, including myself, it took most of my free time and effort to keep it going. It became very popular (and still is). I kept trying to blog, but found my focus and interest waning. Compounding this was the fact that my blog ran on a severely outdated version of ColdFusion and old CF-based blogging software and that it looked hideous on mobile. While nearly 10 years of content has some value, most of the content was outdated and I had no intention of fixing this. Thus, I decided it was time for a fresh start…which is what you are looking at. I don’t plan to blog frequently, but occassionally. I know my audience will be limited, but…so what?! My audience back in 2005 was 1 - just me.

Posted by on 1 July 2014 | 5:15 am