Yesterday, a Hacker News thread started about the recent yuilibrary.com site re-launch. The new template had drawn a good deal of praise from various Friends of YUI on the Internets over the previous few days, which made everyone feel pretty good.
But Hacker News lives very much outside the YUI community bubble, and feedback there was more mixed. One of the earliest comments set the tone:
While YUI is probably one of the best JS frameworks around the sloppy design of their webpage beats me. the yuilibrary.com looks so 90ish in its design.
Instead of letting the thread sit out there and rot, YUI engineer Ryan Grove quickly responded with:
What parts of it strike you as sloppy? How would you improve the design? We’d love to hear specific feedback.
And got comments like:
* Use a fixed-width site. Most people go for something like 960px. * Establish horizontal and vertical eyelines or columns. * If you're on Github, might as well use gists. Offer example projects as open projects on Github
+1 on the fixed width. I'm a developer, so I have a big monitor -- it's hard for my eye to follow sections of the document without lined up elements.
Trebuchet feels dated, especially when bolded and part of blue + orange scheme. That look was very trendy a few years ago. Also, too many faces. Two faces usually work fine...
... I know you have your own CDN but can we have back a "Download" button? I hate it when I have to search for 5 minutes to find out how to download something. It really makes me feel like the whole project is going to be a pain in the ass when even downloading it is hard.
About two hours later, Ryan responded again with:
Great feedback, everyone. I've pushed a few quick changes to address the low-hanging fruit: - We're now using Maven Pro for headings (no more Trebuchet). - Replaced Lucida Grande with Helvetica in the nav bar (sorry Windows users, you get Arial). - The site now has a max width of 1200px instead of expanding infinitely. This seems like a reasonable compromise, since any purely fixed-width design draws the ire of people who hate fixed-width designs. Keep the feedback coming!
We wanted to emphasize the CDN over downloads, but we clearly hid the download links too well. I've added a "Downloads" link to the "Quick Start" dropdown menu in the top nav bar, and we'll give some thought to adding a more prominent link somewhere on the front page. Thanks for the feedback!
Not everything got fixed immediately, but some easy changes got pushed right away. And just like that, comments like this started appearing:
Thanks! That's a pretty amazingly quick response and makes it way easier to find.
Wow, that was fast.
All of a sudden with all of rgrove's (YUI's) interaction, it makes me feel all warm and fuzzy about using YUI again. Great customer service does make a difference.
No doubt not everyone was 100% satisfied, but the thread stayed popular for a good part of the day, and I think most folks came away with the feeling that the YUI team was responsive and effective. After all, they were in fact being responsive and effective. All in all, a good result.
However, the lesson here for the field of community management (at least when it comes to software products) is actually pretty grim.
The idea behind community management is that rather than letting feedback sit out there and decay, you have a professional someone whose job it is to come in and keep things from spiraling out of control. Talk to the people. Gather up the features and bugs. Communicate changes. Let people know that you’re listening.
But “listening” and “participating in the conversation” are weak sauce, and everyone knows it. It’s action that matters.
Having a community manager who is also a working engineer or a product manager makes sense to me. Those are people who can push changes. The icing on the cake is if your product allows for pushing simple changes very quickly. But even without that, just having real authority and knowledge over the timeline makes a world of difference.
By contrast, the classic dedicated community manager is someone who is bright and socially adept, someone who can funnel information back and forth, but who lacks real product authority. After all, you don’t want to waste a product person’s time doing that stuff, do you? Way too expensive. And they would suck at it. No, you need someone specialized.
More and more, that whole line of thinking seems like a huge trap.
Evan, I have to disagree. Maybe that’s because I’ve been at this for so long that “community manager” was a job title I was surprised to find I had, rather than something I thought sounded fun when I’d just graduated and was looking for my first job.
Your community manager is in many ways the voice of your site. Putting a lightweight in that position is the equivalent of hiring that same lightweight to answer your company’s email without giving them any training or supervision.
The single point I most regret not making early and often when writing about moderation and community management is that *it’s not cheap.* “Community management” doesn’t mean “I don’t need to hire someone to do that — the community will handle it,” or “I got sold a software package that ‘enables community moderation’, so that should be enough.” “Community manager” does not mean “Someone who’s spend hundreds or thousands of hours on Racebook but has never participated in any other forums.”
Some organizations will get this wrong, but there’s nothing in this world that some organizations won’t get wrong. Meanwhile, other organizations will get it right. The excellence of Ars Technica’s forums is one of the reasons they sold to Conde Nast for as much as they did.
Hi Teresa,
It’s extraordinary to have you comment on this subject, so thank you.
I don’t think we disagree all that much — I’m also saying that community management, if it’s worth doing at all, is not free or easy.
This piece is more about the specific area of community managers who are supporting software products. Users complain about something being technically broken or suboptimal — and the community manager doesn’t have any power to fix anything or even say anything definitive about when something might be fixed.
That’s a different situation from a community manager who is working to keep the level of discourse healthy on a high-traffic discussion board. Where the whole point is the discussion. I *completely* agree with you that you cannot afford to put a lightweight in that position either.
The TL;DR of the post above is sort of trivial: community managers need to have enough power to do their work. 🙂 A corollary to that is — if you are supporting a healthy software project, part of that power is your ability to rapidly turn around at least some software fixes. That’s all.
Hi Evan, thanks for the post, and I definitely agree. I’ve been online-gatherer/first-responder for Macromedia and now Adobe for quite awhile, but nothing beats having a product team directly involved with their own customers.
(On Teresa’s point, generalists can complement specialists… different skill sets, different needs. If there’s only one side or the other, though, then there’s less of a balance.)
tx, jd/adobe
One problem with this principle, of course, is that if the product in question is much bigger and more complicated than an informational website, it can be quite difficult to give people a meaningful time-table of when some problem might get fixed. You can say, “we’re aware of that, it has an open case in our bug-tracking software, and there are N people assigned to work on it,” but that won’t necessarily scratch the itch for the users complaining about it, if you can’t say with certainty, “it will be fixed in the next version, to be released on date X.”
Yes, I’m aware that modern websites are much more complicated than the HTML pages of yore, and require real expertise to truly understand; I’m not running down the skills of talented web designers and tech-doc folks. I probably could do that kind of work if I wanted to spend the time to learn the new technologies, but it would also likely require *forgetting* the stuff I learned about web design in the late ’90s and early ’00s. In any case, while it’s true that a modern site is more like a functional software product than old static pages, in many ways the complexity has made it *easier* to be responsive — like, if you want to alter the font faces, you can do it in a single stylesheet and push it across the entire site, in a matter of minutes.
Some software is very complicated. And some software products shoot themselves in the foot by making even very small changes slow and difficult. Even so, John’s point (and mine) still stands. The product team needs to be able to speak directly with the customer, because they are the ones actually responsible for fixes.
I think you are correct that having a product team/manager that is involved and responsive to the community is important but I don’t think this replaces a community manager. In fact,I think the example you give is a bit of an outlier in many respects as it works within particular contexts but not as a general rule.
Firstly, being at a company like Adobe (just like JD), often I find I can add value for the community by being a point person who can help navigate the system, so to speak. I have insight into who might best be able to respond to a specific issue within a large company where the product teams are also often quite large.
For the product teams, I can also add value by monitoring these sorts of discussions that are happening in an ever growing variety of venues and communicating them internally. This frees product managers and team members to focus their time on product development and addressing issues rather than sifting through forums, blog posts and social media to occasionally find that nugget of valuable feedback.
You are correct that this may come at the expense of a quick fix in a scenario like the one you noted – but I think those scenario’s are really quite rare. Most software issues, especially in large, widely-used software, cannot be fixed and posted within minutes.
Thanks for the thoughtful post. It really got me thinking.
Hi Brian –
You (and Auros) are right, there are a lot of situations where you cannot push out fixes in minutes or hours. And you (and John) are right that generalists can complement specialists. With those points granted, let me spin a story for you — a bit of a fairy tale, but just something to think about.
Consider a sophisticated beast like, say, InDesign. A user in the forums complains about something minor, like some keyboard shortcut is broken or some menu item is misspelled.
You flag this to the product team, spawning a ticket. An engineer picks it up. “Oh, geez. Oops. Well, this is a three line change.” She commits the fix, your continuous integration system rebuilds InDesign successfully, tests pass, etc.
Within a day, you reply to the user with a screenshot or video showing the feature working. “The fix is in build 31234.09821 and will be released in the next patch.” That patch could be many weeks out, but still — you just need to prove to community that fix is done. That kind of thing is *huge*.
Now this presupposes that the product team has good internal build & test processes. And that they’ve reserved some time and allow engineers discretion for hotfixing certain bugs reported by the community. Most of all, that they’ve given the community manager real authority to affect the product.
That last point is what I’m trying to get at. I’ll grant that community managers don’t necessarily *have* to be an engineers or PMs. But they do have to have real clout internally. In a job interview, here are the two questions every community manager should be trying to get answered:
1. What kind of product authority does this role have?
2. On a scale of 1-10, how fucked up is your software release process?