Those of you who have been keeping score surely noticed that I’ve saddled the iteration of ReportingOn that launched late on July 1 with a “2.0” label when I talk about it. Many of you might remember what the backchannel for beat reporters looked like before the clock struck “late” on July 1:
That’s what it looked like, and it did some interesting things, but not as much as I would have liked. And so began the process of building 2.0. And with it, the cataloging of lessons learned from the first run.
Here’s what it looks like now, almost two weeks after the launch of the new site:
So, what were the lessons that I learned to help make the jump from 1.0 to 2.0? Here’s the key slide from the presentation I gave in a few places during the development of ReportingOn 2.0:
DIY has its limits
I was limited by my own skill and knowledge when it came to web development on the first run. I was teaching myself Django in the middle of the night and early in the morning over coffee, gleaning the important parts from a variety of open source Django projects and friends. Hiring a development and design team solved that. And it solved it well. I haven’t touched a line of code in ReportingOn 2.0, but with the code I soaked up on the first try, I understand its structure and syntax.
What’s my motivation?
(Note the score in the lower-right corner of Joey’s avatar.)
A points-based system in RO 2.0 helps feed the egos of power users while acting as a guide, beat-by-beat, to who might have a good answer for your question. There are still leaderboards to be built, and I’m thinking up other ways to use the points system to motivate users, especially as the network gets off the ground.
Twitter is faster than me
Right, so 140-character limits are long-gone in RO 2.0, and the straight question/answer session should (theoretically, at least) make for longer conversations with more depth to them. As has been pointed out more than a few times, Twitter is a good place to start an argument, but a really poor place to finish one. Although I’d hesitate to frame the sort of exploratory, qualitative Q&A that could happen on ReportingOn as “argument” or “debate,” I’d like to believe that highlighting a “good answer” as noted by the person who asked the question will help lead to a permanent archive for reporting resources in a way that Twitter simply doesn’t do.
To put a finer point on it, if I ask a question of my followers on Twitter and I get a great answer, I get it in a stream of replies that are useful to a certain subset of Twitter users at that moment, but fly right by in the stream and never come back unless I pull them out of the flow of Twitter and display them somewhere. At this particular moment in time, Twitter’s search functionality is highly ephemeral in nature, as it starts and stops indexing from time to time, and rarely dips back in the chronology as far as might be useful. So where the quick-answer utility of Twitter stops, the long-term archive of ReportingOn begins.
Translate this?
This is the Great Unchecked Box on the list of development paths to explore, and it’s pretty critical. When ReportingOn 1.0 launched in October 2008, Spanish- and Portuguese-speaking journalists were among the users most excited about it. A few even translated the FAQ into other languages and made all sorts of great suggestions via email, Twitter, and their blogs as to how I might implement some sort of translation tool, or a choice of language for each user.
So how do other social networks handle this? Facebook actually crowdsources the translations of the “chatter” on their site via a Facebook application. (When I say “chatter,” I mean the documentation and little bits of stock verbiage that come in between all that content you create on the network.) Now, getting the chatter right is important, but in the case of RO 2.0, it’s the content that needs translation.
(Facebook allows users to choose from a wide range of languages to view the social network in, but they translate the text created by Facebook, not the content of your friends’ posts and comments.)
The whole point of the network is to bring together journalists in disparate places working on similar beats, so I’ve rejected any method that divides up the streams of questions and answers based on language. (Of course, a Spanish-speaking journalist would be free to use the existing open source codebase of RO 2.0 to build their own version of the site.)
That leaves something like the Google AJAX Language API as an obvious option. How would it work? Well, if you’re looking at a question posted in English, you might have a button that says ‘Translate This!’ which leads to a little pop-up menu allowing you to choose a language, then the translator would run and display the question in the language of your choice. If you’ve ever used Google Translate on a web page or a block of text, you know how spotty it can be, but I haven’t seen a better solution yet.
Public Relations Sharks
Ah, the sharks. Well, while there’s no “tag this shark” button in the system yet, as use of the network ramps up, I’m hoping that any impositions made in answers by my friends in the public relations and marketing fields will simply not be marked as ‘good answers’ and without positive feedback, the sharks will lose interest.
(“Shark” by Jeff Kubina on Flickr.)
But, I think there’s plenty of room for a better answer to this problem. One option I kicked around with the development team was to let users “flag” a problematic user; but one flag alone didn’t change anything; it would take five or ten flags before the user’s answers would either not be displayed to others, or perhaps their answers would be collapsed down to only display their username and a flag. Interested users could click to view their answer, or maybe set a threshold-style switch in their profile to ‘always view answers from flagged users.’
What’s next?
We’ll see. The development team has some bits and pieces of time to finish one or two features on my wishlist, and then the network will most likely stand as-is until either I pick up some more funding to continue work on it, or until some friendly developers submit some interesting patches. I’m eager to see what they come up with, and how the codebase is used out in the wider web.
