|« September 2005||November 2005 »|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
firstname.lastname@example.org no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
# FanConcert Speculation 1
Now that FanConcert is in the usable state that it's in, it's natural to want more out of it. I'm getting great feedback from users but ultimately, since I'm on a personal deadline of sorts, I need to get it down to:
"What sells? What has value?"
...with the close second "how do I receive people's money in return for this value?" which is also closely related to "how do I keep the site running without begging for donations or selling my organs?" and "how can I live off this site and avoid getting a 'real' job?".
Yes, it's all fun and games until someone loses a kidney. I'm going to try to lay out most of my priorities, strangely enough in no particular order. Some are badly needed, others are just harebrained ideas that I think FanConcert needs to be a success.
FanConcert's login code needs to be reworked, either with an update from the original author or a refactoring from me. It was very convenient to have this pre-made login system in the beginning but the login code in its current state has become a usability problem for FanConcert. Not good.
The payment system needs to be hooked up through a third party company that takes credit cards or other forms of payment and this must be hooked up through the FanConcert's login code. I'm not sure how these two will be connected just yet because I don't know how payment systems work. Investigation is definitely needed.
Ease of submission of data into FanConcert is important. I want to encourage people to submit new stuff and make it as easy as possible to submit the minimum amount of information. Then other people can come along later and add details by editing the object.
Ease of moderation is equally important, since a moderation to me is just a submission that agrees with an existing submission. The more people that agree with a submission, the more likely it is to be correct. On the flip side, ease of moderation will ensure that information the majority of people deem to be incorrect is removed from other users' view.
Once an object has been moderated users should see their mistakes so they can fix them. People make mistakes, it happens. Most of the time it's not malicious, so users will want to know when they made a typo, so they can go back and fix it. Fixing mistakes will improve the user's overall moderation score, which is used for moderation weighting.
Moderation weighting means that user's submissions will be weighted differently depending on a few factors. First, a user may be marked as an authority on an artist, venue, record label, etc. Then anything that user submits about that object will have a higher initial score than other users since it's coming straight from a credible source. This doesn't mean that these submissions can't be overruled, it will just take more users. The difficulty will be authenticating these official sources ... a basic example is verifying they have a [something]@artistname.com email address.
Secondly, each user's submissions will also be weighted based on their past submissions. If a person has a history of submitting things that other users deem are correct, then that user's future submissions will have more weight. The weight for every vote is also floating, meaning that as the user's moderation score improves, the weight for all of the user's existing votes will increase as well. These moderation measures are meant to root out malicious users.
Arbitrary attributes will allow more flexibility in FanConcert. When a user enters a new object, like an Artist, they can fill out "standard attributes" like the artist's name and country of origin but also add custom attributes for whatever imformation they like that isn't covered by the standard attributes, such as "year formed". With enough demand an arbitrary attribute could become a standard attribute.
Personal tagging will let users tag an object with any tag they like, such as "I attended this concert", "I have this album" or "this Artist sucks!". These custom tags can be used sort/subdivide large lists of objects, like bands you're interested in. Then you can use these smaller subdivided groups of objects in personalized pages and RSS feeds.
...and last but not least, my personal favourite: output templates, a subscriber feature. All of the data in FanConcert is arranged so that it can be easily rearranged and reformatted. Why not allow users to create their own personal output templates for this data? Then users can create their own RSS feeds, or any type of "output" feed actually, even their own HTML pages.
It would save me a lot of work, wouldn't it? Mostly because I'd let people share their output templates with other users. Paying users could use output templates to act as an API for some other application they connect to FanConcert. They pay for their subscription, and I allow a finite number of "reads" with their account and make sure multiple people aren't using it. Then other users can also subscribe to FanConcert, use that user's application and his FanConcert output templates.
FanConcert could also have a CDDB-like business model where the application's business pays FanConcert for a finite number of "queries" and the users of the program get "free" access and are none the wiser. For example: when you use iTunes, Apple pays CDDB to get CD track listings and you don't pay anything.
FanConcert in that context is a web service and the API is completely customizable instead of some restrictive RPC XML or something. I think this would be really neat for subscribers, what do you think?
# FanConcert Dev Process Retrospective 1
After hitting a small roadblock on FanConcert, I figured now was a good time to sit back and (1) take a short break, since I've been working 8-12 hours every day since the beginning of August, (2) take a step back and look at the big picture for a little while (3) catch up on the Rails community.
Concerning (1): the break was good. I stopped drinking caffiene at the same time and realised that I was actually in more sleep debt that I thought (hint: not good). A few days off the juice was needed -- and after about 48 hours of headache I was all good.
Concerning (2): it's a real testament to the agile iterative process that FanConcert is what it is. It's a block of clay, slowly taking shape. Sure it still doesn't do very much and it doesn't look very nice but it's been LIVE since week 0 and people have been using and commenting on it ever since.
The not-so-obvious downside of the "live iterative strategy" is that people aren't used to using incomplete anything, let alone websites. I've been spending a lot of time explaining why the finer details of the site aren't a priority and especially why the site doesn't look pretty.
I don't blame people for this, it's just a natural response: people are used to using polished websites. But I've learned a lesson: I now expect that kind of feedback and I write it down so I can use it when the time comes to use it. It's when a certain fine detail becomes a distraction from more important feedback that I realised I had to handle it to a certain extent.
When the site was just links and a white background, most people's first comment was that it lacked colour. I thought it was a pretty minor detail, but after getting that feedback a dozen times and nothing much else, I realised I needed to remove that distraction: I added a bit of colour to the background, and now people are giving better initial feedback because they aren't distracted by the lack of colour. These distractions are easy cop-out feedback, so I felt it was good to get that one out of the way, and it didn't take much effort.
Concerning (3): Rails is a moving platform, it hasn't even hit 1.0 yet. Version 1.0 is a symbolic milestone, I know, but some developers still take it seriously, like I believe the Rails people will. Rather than update to 0.14.x, I'm going to wait until 1.0 plus a few maintenance releases. I don't have the resources to keep up with every single point release and I'm not using any crazy code, so the post 1.0 upgrade should be relatively painless. Besides, I've read that the Rails team is concentrating more on backwards-compatibility and careful deprecation, which makes upgrades nicer.
Other than not upgrading, I'm also missing out on what's going on in the Rails community while working so hard on FanConcert. I don't think it's a good idea to be out of touch with the community for so long. Not just for the new stuff but also for time-saving tips and APIs and methods I may not know of yet that could help me. I'm still learning Rails, so I should be "taking advantage" of the great Rails community more often. It really is a fantastic support network.
I'm going to take my head out of the sand for a little while while I'm doing the "big picture" things, see what's going on and then get back to work again.
Anyway, that's my little retrospective. Nothing specific to FanConcert there though, it was mostly process details ... probably some feature stuff in a future blog post.
# Unequal Voices
Exactly. There's no moderation system in a wiki, it's a free-for-all. An improvement on a collaborative website could:
- Identify people who have expertise or knowledge on certain subjects.
Then in the pool of the remaining non-"experts" you would have to seperate:
- The careful researchers who find and submit factual information, even on subjects where they are not experts.
Push all of that into a moderation scheme and you've got something more reliable than a free-for-all wiki. The experts get more of a voice and the saboteurs get much less.
The downside is that it's likely to be far more complicated and that reduces the barrier of entry, which in turn reduces the number of people that are likely to collaborate.
The upside? Like I mentioned before, Wikipedia has already paved the way. People will be more likely to collaborate now even though it's more difficult because:
1. They already have seen it work on Wikipedia. They know the benefits of submitting: that their work won't go to waste and will be enjoyed by others.
Wikipedia was never very good at crediting people -- credits are shoved in the back end with the edit history. This makes almost every Wikipedia article effectively anonymous. That in turn reduces an individual's personal responsibility to the facts because it's difficult, though not impossible, to trace errors to specific people/users.
If you insert some personal accountability measures into your new collaborative website, all of a sudden quality improves. Imagine that. Sometimes it's as simple as putting people's names on their work, like Everything2 does.
# Wikipedia Paves the Way for Massive Collaboration
Wikipedia.org has been taking some slack lately. Wikipedia-bashing seems to go in cycles with the press and then the blogger ripples that follow, this time itself a ripple of the Web 2.0 hype. Wonderful.
The focus seems to be on Wikipedia's quality problems and an apparent willful ignorance of those problems by the Wikipedia faithful.
But honestly, if you really liked Wikipedia and you couldn't come up with a reasonable solution to improve quality, what would you do? You'd probably just keep trying to fight the good fight against users bent on creating chaos. Wikipedia is a great informal reference. Would I use it for anything serious? Not as a primary reference, no way. I don't think anyone in academia would either -- and that can't be a good sign.
Wikipedia cannot overcome its technical limitations that cause the quality problems. That's why it will never be an encyclopedia. The sad thing is that its technical limitations are a side-effect of its technical innovation -- the fact that it is a collaborative wiki that can be edited instantly by anyone.
A wiki can only be so reliable, so correct. There will always be saboteurs and there will always be a finite amount of time required to clean up after them. This is not an environment for a real encyclopedia but it's a great environment for an informal secondary resource.
I applaud what Wikipedia has done, I think it's great. I use it almost every day, and every day I learn something from it. But I don't think I'd dare call it an encylopedia, at least not a reliable one. It's pretty good, but that's just not good enough.
The good thing is that this is the first step in a long line of collaborative "fact repositories". The editorially-relaxed (nay, free) Wikipedia process was the only way collaboration of this sort could initially gain a foothold.
People have seen the benefits and downsides of massive collaboration. People have learned from Wikipedia. Now it's time to get serious about online resources that can leverage massive collaboration for comprehensiveness but can still be a reliable source.
A wiki just isn't going to cut it for that purpose, folks. We need some new ideas.
# If You Can't Take the Noise...
The city of Ottawa is spread out: we don't have a very large or dense city core here. City council has been trying to increase population density in the core to reduce "urban sprawl" and traffic problems. That makes sense, right?
Except that more and more people are living downtown, next to the bars and the nightlife. Then these people have the audacity to complain about the noise from these bars, using the noise bylaws as a crutch.
The noise bylaws, the bars and the patrons are not the problem. The people moving downtown with hefty expectations are the problem.
If you move into an apartment in The Market or on Elgin Street in Ottawa, you know what you're getting into. The bars have been there for decades. Don't give us this bull, don't make a fuss. If you don't like it you can -- and should -- move someplace else.
Leave our nightlife alone.