Some examples I’ve come across over the last few days:

Designing out functionality: Verizon

Squub on Squublog, mentions a case of a product’s features being deliberately disabled with some intent (though it’s not clear exactly what benefit Verizon would get from doing this – does anyone have any ideas?):

“When I bought my Verizon 6700 Pocket PC “phone”, the operating system was “enhanced” so that the thing could be used as a phone OR a wi-fi device, but not both at the same time. In other words, if I turned on the wi-fi, the phone wouldn’t ring if anyone tried to call me. There’s a registry hack that disabled that feature… or re-enabled the intended functionality… or whatever.”

The thinking behind adding control

Over on Metafilter, ‘onhazier’ talks about some of the rationale behind designing restrictive control into software:

“I work for a software company where we continually ask if a control is necessary. We actually debate “What is the harm of letting the client do XXXX?” Sometimes, we determine there is no harm and do not restrict the choices available to the client. At other times, we have to restrict the choices to make sure our software complies with various laws or industry standards. There are many reasons for implementing controls in software such as keeping a client out of a loop or guiding them through a process in a user friendly manner.”

This is a useful insight, and parallels the same kinds of thought process that engineers and designers often go through when designing safety or mistake-proofing forcing functions into products. These are architectures of control intended (at least) to be useful or beneficial to the user, or to the community as a whole (often contentious, e.g. skateboard ‘deterrents’).

But, as can be seen from the analysis of examples (and the diagram – both of which need quite a bit of updating), there are also many design examples where the intentions behind the control are not in favour of the user, but instead the design is driven by political, or more usually, purely commercially exploitative strategy.

Viral control

Medialoper has a great piece on Microsoft’s Zune ‘viral DRM’:

“Zune will intentionally infect your music with the DRM virus before passing it along to one of your friends. After three listens the poor song dies a horrible DRM enabled death… Microsoft will undoubtedly claim this limitation is designed to support artists and prevent piracy. There’s just one problem… While it may come as a surprise to Microsoft and the major labels, independent musicians frequently promote their music by posting unencrypted mp3 files on their websites in hopes of finding an audience… [and] it appears that Zune’s viral approach to DRM is in violation of all of Creative Commons licenses. It’ll be interesting to see how long it takes before someone actually challenges Microsoft on this.

What happens if someone tries to protect a CC-licensed work with digital rights management (DRM) tools?

If a person uses DRM tools to restrict any of the rights granted in the license, that person violates the license. All of our licenses prohibit licensees from “distributing the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement.”
Creative Commons FAQ

It’s not clear whether this ignorance/overriding of Creative Commons provisions is deliberate (and strategic – to prevent artists who choose CC licensing from gradually dominating the Zune network?) or just incompetent/lazy: Medialoper quotes Microsoft’s Cesar Menendez:

“There currently isn’t a way to sniff out what you are sending, so we wrap it all up in DRM. We can’t tell if you are sending a song from a known band or your own home recording so we default to the safety of encoding.”

Even if “the safety of encoding” means violating an express intent by the originator of the content?

Frustrating interactions

In some cases, the line between user frustration due to deliberate control and awkward or poor interaction architecture is a blurred one – for example, Matías e-mailed me details of a change to the way iTunes allows users to organise their files:

“I believe that the new iTunes store is a good example of increasing control of the users’ behavior. In the previous version (6.something) all your files ended up together at the library, and you could choose how to organize them, listen to them, etcetera, with pretty much absolute freedom (for example, if you sorted your files by the date you added them, you could play a combination of mp3s of your favorite free music alternating with podcast of your choice). Now, if you listed to music is just music (or whatever you put in an mp3), if podcasts is, podcasts is, and so forth. Unless you spend your (apparently) worthless time creating a playlist, no more freedom for you on iTunes.”

It’s not clear what the intentions would be behind this kind of design change – is there any commercial motivation in Apple’s choice to restrict users’ behaviour in this case, or is this just an example of an irritating alteration to the method of interaction?