Inércia Sensorial


Form plan

Filed under: Perils of Software Development — inerte @ 17:09

Des Traynor talks about interfaces on this podcast and hit the nail on the head. You need a plan, a grand vision of things before writing software. Or at least know what tasks you want your users to accomplish.

So let me tell you what happened while I was developing a gaming website based on social network concepts.

Most game review websites have a score divided into 4 or 5 categories. The ubiquitous graphics, some will score sound and gameplay, and some will put a score to even things out, like Gamespot’s “tilt”, which can drive a fun but ugly game score up. Sum them, divide by the number of categories, and you have the final score. Others will rate games using directly one score: From 0 to 10, 0.0 to 5.0, E to A.

So I sat down and started coding the form to let users write game reviews, and it had the following fields: Title, Summary, Body, The good, the ugly, and 5 rate categories (graphics, sound, gameplay, value and tilt). The same fields that a review has on Gamespot.

Then I decided to drop the graphics rating. My personal opinion is that the gaming industry (including the press and the hardcore gamers) put too much value on graphics, and that’s not what games are about. They are about FUN. Inside that mentality, that the technical merits of a game don’t make them better than others, I also dropped the sound category.

And since value is relative, we have many different models today, like subscription based, or cost-per-action (like Xbox Live), we have people that just buy pirated games (specially here in Brazil), I dropped the value rating. That left me with only two ratings, so I decided to drop them too since I had the feeling that the project was taking its own directions anyway, and two are too many things for the users to worry.

So I wrote a couple reviews to test the system, and it was a tedious and repetive process to write the “good and the ugly” parts, because they were rehashes of the Body. Out they were.

Left only with the Title and Body fields, I dropped the Title because life is complicated enough to waste time thinking about clever phrases. And on a game page, with the list of the latest or best reviews, I thought that a lot of the Titles written by the users would be the same, like “Play this game” or “Avoid it like the [insert bad thing here)”.

I consired having just a single score for games, but the proccess that people do to reach this score is different. In an ideal world, reviewers would rationally consider the game techical merits in its particular time period and plataform. Plus, the gameplay, genre relevance, and fun factor. But asking for objectiveness from video game fanboys is just pure insanity.

So my conclusion was that in the end, what matter about a gamer’s opinion is: Did you enjoy playing it? Anything else is secondary, and on a site that wants to build itself on user-gerated content, the easier that is for users to participate, the better.

So the new review form went from 10 fields to two: A radio input asking if the user enjoyed playing the game and a (optional) textarea for more details.

And the amazing thing is, inside the social network concept, this system works wonderfully. Right after the user reviews the first game, the website starts to recommend games that the user might enjoy based on matches made by gamers that also liked (or disliked) the reviewed game. Throw in a trust system to weed out the disruptive users, and things are starting to look good.

But without a graphics rating, how will gamers find for example what’s the most gourgeous First Person Shooter ever? Well, they won’t, and I don’t regret taking this option from them. Not only because, like I said, I think we should de-emphasize graphics, but because the gamers that care about this aren’t my target market. Sure, 30% of the gaming industry revenues come from hardcore gamers, but I believe that this scenario is changing.

An interface must serve a clearly defined proposal, and it’s the job of developers and managers to figure out what it is before even touching the code editor or the database. Over the web, things have to be even more simple, because the audience has the potential of being larger and more diverse. Each feature added to satisfy an group of users has the chance of creating confusion for others (of course, this is true for web or desktop users). Have a goal and use your imagination, because it’s a good thing to defy the standard “feature wars” of software development and simplify the life of your users.

Powered by WordPress