<?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 complications of watches and language</title>
	<atom:link href="http://www.goodusability.co.uk/2010/07/the-complications-of-watches-and-language/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.goodusability.co.uk/2010/07/the-complications-of-watches-and-language/</link>
	<description></description>
	<lastBuildDate>Thu, 03 Nov 2011 04:50:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Etienne</title>
		<link>http://www.goodusability.co.uk/2010/07/the-complications-of-watches-and-language/comment-page-1/#comment-3541</link>
		<dc:creator>Etienne</dc:creator>
		<pubDate>Sun, 06 Mar 2011 21:11:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodusability.co.uk/?p=2278#comment-3541</guid>
		<description>Hi there,

A short comment to say that in French, we have two different words.

The first one is &quot;compliqué&quot;. It&#039;s sounds very similar to &quot;complicated&quot; and means &quot;uneasy to use&quot;. On the other hand, &quot;complications&quot; is actually a really common term in horlogery world to talk about some kind of watch style. It make me think to the french word &quot;complexe&quot; which means &quot;rich&quot; or &quot;evolved&quot;. This second notion is quite different and actually could be wanted by expert users on some specific web apps in order to improve their professional efficiency.

The only real question is to know if Blancpain website users are familiar to this word ;-)</description>
		<content:encoded><![CDATA[<p>Hi there,</p>
<p>A short comment to say that in French, we have two different words.</p>
<p>The first one is &#8220;compliqué&#8221;. It&#8217;s sounds very similar to &#8220;complicated&#8221; and means &#8220;uneasy to use&#8221;. On the other hand, &#8220;complications&#8221; is actually a really common term in horlogery world to talk about some kind of watch style. It make me think to the french word &#8220;complexe&#8221; which means &#8220;rich&#8221; or &#8220;evolved&#8221;. This second notion is quite different and actually could be wanted by expert users on some specific web apps in order to improve their professional efficiency.</p>
<p>The only real question is to know if Blancpain website users are familiar to this word <img src='http://www.goodusability.co.uk/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hyde :: York</title>
		<link>http://www.goodusability.co.uk/2010/07/the-complications-of-watches-and-language/comment-page-1/#comment-2710</link>
		<dc:creator>John Hyde :: York</dc:creator>
		<pubDate>Fri, 09 Jul 2010 13:11:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodusability.co.uk/?p=2278#comment-2710</guid>
		<description>I would go with &quot;watch features&quot;.

I would also turn the features into benefits where possible. 

Not empty marketese - like &quot;state of the art&quot;, &quot;world-class&quot;, etc. 

No - just straightforward explanations of why the features will be useful to the buyer / owner. This applies even in technical B2B sales. The person buying a semi-conductor foundry cannot know everything there is to know about the kit - or he would be making his own. So he needs to understand why the case is made from X or the input hopper is at the back. And why this will help him.

Going back to the watches - I wonder what their conversion rate is and how long an A/B split test would take to decide if &quot;complications&quot; is better than &quot;watch features&quot;.</description>
		<content:encoded><![CDATA[<p>I would go with &#8220;watch features&#8221;.</p>
<p>I would also turn the features into benefits where possible. </p>
<p>Not empty marketese &#8211; like &#8220;state of the art&#8221;, &#8220;world-class&#8221;, etc. </p>
<p>No &#8211; just straightforward explanations of why the features will be useful to the buyer / owner. This applies even in technical B2B sales. The person buying a semi-conductor foundry cannot know everything there is to know about the kit &#8211; or he would be making his own. So he needs to understand why the case is made from X or the input hopper is at the back. And why this will help him.</p>
<p>Going back to the watches &#8211; I wonder what their conversion rate is and how long an A/B split test would take to decide if &#8220;complications&#8221; is better than &#8220;watch features&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Keith Bell</title>
		<link>http://www.goodusability.co.uk/2010/07/the-complications-of-watches-and-language/comment-page-1/#comment-2708</link>
		<dc:creator>Keith Bell</dc:creator>
		<pubDate>Tue, 06 Jul 2010 12:15:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodusability.co.uk/?p=2278#comment-2708</guid>
		<description>I agree, David -- &quot;features&quot; seems like the most appropriate navigation label in this case by far. &quot;Complications&quot; smacks of &lt;a href=&quot;http://www.webpagesthatsuck.com/mysterymeatnavigation.html&quot;&gt;Mystery Meat Navigation&lt;/a&gt;. To the non-horologist site visitor, &quot;complications&quot; might imply that the watches are complicated to make (not surprising); or worse, that they are complicated to use or to buy -- an impression that I doubt Blancpain would wish to convey.</description>
		<content:encoded><![CDATA[<p>I agree, David &#8212; &#8220;features&#8221; seems like the most appropriate navigation label in this case by far. &#8220;Complications&#8221; smacks of <a href="http://www.webpagesthatsuck.com/mysterymeatnavigation.html">Mystery Meat Navigation</a>. To the non-horologist site visitor, &#8220;complications&#8221; might imply that the watches are complicated to make (not surprising); or worse, that they are complicated to use or to buy &#8212; an impression that I doubt Blancpain would wish to convey.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Hamill</title>
		<link>http://www.goodusability.co.uk/2010/07/the-complications-of-watches-and-language/comment-page-1/#comment-2709</link>
		<dc:creator>David Hamill</dc:creator>
		<pubDate>Tue, 06 Jul 2010 08:39:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodusability.co.uk/?p=2278#comment-2709</guid>
		<description>Hi Richard thanks for the clarification. I&#039;d argue that what you&#039;re describing can be adequately labelled features. The display of the time is pretty much a given when you&#039;re buying a watch. So few people would expect to see it listed as a feature. It&#039;s kind of like Apple listing the ability to make phone calls as a feature of the new iPhone. In any case it seems we agree about the central point.</description>
		<content:encoded><![CDATA[<p>Hi Richard thanks for the clarification. I&#8217;d argue that what you&#8217;re describing can be adequately labelled features. The display of the time is pretty much a given when you&#8217;re buying a watch. So few people would expect to see it listed as a feature. It&#8217;s kind of like Apple listing the ability to make phone calls as a feature of the new iPhone. In any case it seems we agree about the central point.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://www.goodusability.co.uk/2010/07/the-complications-of-watches-and-language/comment-page-1/#comment-2707</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Tue, 06 Jul 2010 08:38:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.goodusability.co.uk/?p=2278#comment-2707</guid>
		<description>I think it&#039;s a little more involved than that. A complication isn&#039;t simply a feature -it&#039;s a feature &lt;i&gt;other&lt;/i&gt; than those entailed by the display of hour, minutes and seconds e.g. dates or sunset times. So it does have a very specific meaning that&#039;s not all that easy to translate into everyday language. Enhancements might be the best simple term.

I tend to agree with you that it depends on the product positioning and audience. The bias towards simplicity is also reasonable in principle; however, I also think it can sometimes be possible to have an excessive bias in that direction. One site I worked on was in telecoms and the internal assumption was that users were not interested in technical features; they wanted to know about the everyday business benefits they could gain from the product. In testing, this assumption was proved wrong; the users (all of whom were technical personnel in various roles) ignored the benefit material as marketing fluff and wanted to know answers to detailed technical questions that often weren&#039;t covered on the site. The benefits assumption really related much more to internal aspirations than about the actual usage patterns. That doesn&#039;t obviate your point at all of course (given that the technical features had to be explained in a way that catered to user&#039;s withh varying degrees of expertise in the area), but we should bear in mind not to underplay the user&#039;s domain knowledge.</description>
		<content:encoded><![CDATA[<p>I think it&#8217;s a little more involved than that. A complication isn&#8217;t simply a feature -it&#8217;s a feature <i>other</i> than those entailed by the display of hour, minutes and seconds e.g. dates or sunset times. So it does have a very specific meaning that&#8217;s not all that easy to translate into everyday language. Enhancements might be the best simple term.</p>
<p>I tend to agree with you that it depends on the product positioning and audience. The bias towards simplicity is also reasonable in principle; however, I also think it can sometimes be possible to have an excessive bias in that direction. One site I worked on was in telecoms and the internal assumption was that users were not interested in technical features; they wanted to know about the everyday business benefits they could gain from the product. In testing, this assumption was proved wrong; the users (all of whom were technical personnel in various roles) ignored the benefit material as marketing fluff and wanted to know answers to detailed technical questions that often weren&#8217;t covered on the site. The benefits assumption really related much more to internal aspirations than about the actual usage patterns. That doesn&#8217;t obviate your point at all of course (given that the technical features had to be explained in a way that catered to user&#8217;s withh varying degrees of expertise in the area), but we should bear in mind not to underplay the user&#8217;s domain knowledge.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

