<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Twitter settings update as a lesson in web usability</title>
	<atom:link href="http://philipjohn.co.uk/the-twitter-settings-update-as-a-lesson-in-web-usability/feed/" rel="self" type="application/rss+xml" />
	<link>http://philipjohn.co.uk/the-twitter-settings-update-as-a-lesson-in-web-usability/</link>
	<description></description>
	<lastBuildDate>Tue, 07 Sep 2010 16:28:26 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Adrian Short</title>
		<link>http://philipjohn.co.uk/the-twitter-settings-update-as-a-lesson-in-web-usability/comment-page-1/#comment-117</link>
		<dc:creator>Adrian Short</dc:creator>
		<pubDate>Wed, 13 May 2009 20:20:47 +0000</pubDate>
		<guid isPermaLink="false">http://philipjohn.co.uk/?p=389#comment-117</guid>
		<description>I don&#039;t think the issue here is about choice per se but about breaking implicit promises, or at the very least, defeating reasonable user expectations.

Endless reams have been written about the problems of giving people too many choices and how that can hurt an application&#039;s clarity and usability. As with all things, it&#039;s about getting the balance right. Most things are neither one-size-fits-all nor completely configurable in every respect.

Unless you have some kind of formal democratic structure otherwise, running a web application is a dictatorship, though if you want to keep people on board you need to find ways of making it a benevolent and harmonious one.

What Twitter did wrong was to make an arbitrary decision without any consultation and present it as a fait accompli. It would cost little to get into a conversation with users about plans for things like this, and as you say, maintain reasonable existing features unless there&#039;s an utterly compelling reason to do otherwise. My judgement in this case would be that it would benefit Twitter far more to keep this option as it was than to remove it.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think the issue here is about choice per se but about breaking implicit promises, or at the very least, defeating reasonable user expectations.</p>
<p>Endless reams have been written about the problems of giving people too many choices and how that can hurt an application&#8217;s clarity and usability. As with all things, it&#8217;s about getting the balance right. Most things are neither one-size-fits-all nor completely configurable in every respect.</p>
<p>Unless you have some kind of formal democratic structure otherwise, running a web application is a dictatorship, though if you want to keep people on board you need to find ways of making it a benevolent and harmonious one.</p>
<p>What Twitter did wrong was to make an arbitrary decision without any consultation and present it as a fait accompli. It would cost little to get into a conversation with users about plans for things like this, and as you say, maintain reasonable existing features unless there&#8217;s an utterly compelling reason to do otherwise. My judgement in this case would be that it would benefit Twitter far more to keep this option as it was than to remove it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
