Sunday, March 17, 2013

Area 51 is Broken


Recently, the Arduino site proposal was hit by a serial downvoter. On my last count, every question had received at least one downvote so thats about 50 downvotes spread across two pages (Someone really considers this as a bad proposal idea). I thought this was wrong (how could it not be?) and the issue was brought to the attention of the Community Team. However, what happened next, really surprised me. One of the Community Managers looked into it, and responded with :

 I looked at the actual voting data on the example questions and there is one person who cast a large number of downvotes. It looks like there's a user who doesn't think the proposal should go through or that the proposed questions belong to it, which is entirely fair. This is exactly what Area 51 is for.

The one thing that stood out here was that, downvoting all the questions on a proposal page is an acceptable way to not-support or block a proposal. What I find even weirder is the fact that this is the only way to block a proposal (not considering duplicate proposals, in which case there are other ways). So, I believe that Area 51 is broken. What do I mean by broken ? Have a look.



I dont agree with a lot of the stuff said in the video, but I do agree with the main point.
If I think its broken, its broken.
Dont worry, thats not going to be my only argument in this post.

Stack Exchange is a service and earns its money off user data and user actions on the site. So, having a good interface is pretty much one of the basics. Just to be clear, the overall Stack Exchange user interface is really good and functional, it is just Area 51 that seems to belong to a different age and time.

It is only here that the functionality and usability dont match which goes against a simple UI design principle :

The principle of context -- Limit user activity to one well-defined context unless there's a good reason not to

What this principle states is that an action should have a single function and should work in a single context. As an example, lets look at the Back button on your browser. Its action while in the middle of a browsing session is to simply take you a logical step back, that is, one web page back. What happens if you are on your first page ? There are two possibilities here, either it could simply not function and provide a message saying that you are on your first page or it could limit the action to the specific context and close your browser window. Now, lets see what actually happens in real browsers. When you open up Chrome (or Chromium), and are on your home page, you see this :


Freehand Circles. Sigh.
The back and forward buttons are grey-ed out. You cannot actually quit by clicking on the back button. Here, the action is preserved to a single context. I believe this to be a better design methodology considering that you will be catering to users having varied expertise levels in using computers. Of course, this rule has a conditional attached to it. However, coming back to the Area 51 user interface, I really see no good reason for the downvote action to be used in different contexts. The UI itself is far from being cluttered. Its more minimalistic than what is present on other sites.

This actual usage goes against another design principle :

The principle of shortcuts-- Provide both concrete and abstract ways of getting a task done

The principle here is that there should be both long and short ways of doing a task. As users become more experienced with an application, they tend to migrate from the longer method to the shorter method. This principle, also implies, that the user interface should make common actions accomplish-able in the minimum number of steps.

Lets go back to Area 51 now. When a user sees a proposal idea, the two possible reactions are either that the user likes the proposal idea or does not like the proposal idea (internet browsing individuals are opinionated). If a user likes a proposal idea, then the most basic action that a user can do is to support it, by clicking on the Follow It! button.

However, if a user wants to do the alternative, then there is no visible option. I see how this protects proposal ideas from getting bombed by malicious users, but what it misses is a large part of the dont like opinion.

Now, the proposal has a lot of example questions underneath. If you think that a question is a good fit for a site, then you can upvote it. If you dont think it is a good question for the site, then you can downvote it.

Upvote Tooltip
Downvote Tooltip








This feedback is directly sent to the question poser, who had put in time to think about how to develop the proposal and what it should include. Simple. Users who are interested in the proposal can use these options to improve the proposal and provide constructive inputs, as is suggested by the tooltips. However, there still is the other faction of users who think that the basis of the proposal itself is wrong, and have had no chance to express disagreement. Now, things get complicated.

Some of the users, who feel that the proposal is a really bad idea, realise that they still can express disagreement by downvoting the questions. Now, a downvote, as I mentioned, is equivalent to negative feedback on the question. It is not for
I'd rather not see this proposed site
(However, I was told that this is just a semantic difference, something that I do not agree with)

It is for feedback on the question, not on the context of the question and there is no way for the question poser to know the context of the feedback. So, this faction is able to implicitly thwart the proposal, by explicitly telling off users on their constructive inputs. The more motivated ones, like the one who caused this whole discussion, may go trigger happy and downvote all of the questions.

So, how can this be avoided ? How can agreement and disagreement both be expressed ?
My take. Coming up soon!

No comments:

Post a Comment