All posts filed under “Engineering

The Hacker’s Amendment


Congress shall pass no law limiting the rights of persons to manipulate, operate, or otherwise utilize as they see fit any of their possessions or effects, nor the sale or trade of tools to be used for such purposes.

From Artraze commenting on this Slashdot story about the levels of DRM in Windows 7.

I think it maybe needs some qualification about not using your things to cause harm to other people, but it’s an interesting idea. See also Mister Jalopy’s Maker’s Bill of Rights from Make magazine a couple of years ago.

The world’s energy meter

Electrcity meter, in a cupboard

One of the presentations I’m really looking forward to at OpenTech 2008 in London is by AMEE, self-described as “The world’s energy meter”:

If all the energy data in the world were accessible, what would you build? The Climate Change agenda has created an imperative to measure the energy profile of everything. As trillions of pounds flow into re-inventing how we consume, we have a unique opportunity use open data and systems as a starting point. AMEE is an open platform for energy and CO2 data, algorithms and transactions.

From this PDF on the AMEE website:

AMEE is a neutral aggregation platform to measure and track all the energy data in the world. It combines monitoring, profiling and transactional systems to enable this, as well as an algorithmic engine that applies conversion factors from energy into CO2 emissions.

# AMEE is a technology platform (a web-service API) , designed to be built upon by you
# AMEE can represent both copyright and open data without conflict
# AMEE is open source
# You can build commercial applications using AMEE

This does sound extremely useful – the ability to convert energy into CO2 emission equivalent “enables the calculation of the “Carbon-Footprint” of anything” – and I’m going to see how I might be able to make use of AMEE’s functionality or the data set as part of the research. (As an aside, it’s interesting how often ‘energy methods’ allow us to compare diverse activities and effects with a common currency: I remember being struck by this concept before when being introduced to von Mises’ criterion in stress analysis and streamlined lifecycle analysis within a few days of each other.)

AMEE’s Gavin Starks also presented at O’Reilly’s ETech earlier this year (one day I’m sure I’ll go to this…) and the slides are available [PDF, 8MB]. On a similar theme, the very impressive Saul Griffith (of MIT Media Lab, Squid Labs, Instructables, Make et al) talked on ‘energy literacy’ – again, a detailed presentation [PDF, 7.6MB] with thoughtful notes (see also Wattzon) – and it seems that there is a certain degree of overlap, or symbiosis between the ideas. We need a public literate in energy to care enough about measuring and changing their behaviour; we equally need good and understandable energy-using behaviour data to enable that public to become literate in the consequences of their actions, and indeed for ‘us’ (designers/engineers/technologists/policymakers…) to understand what behaviours we want to address.

I’d like to think that Design for Sustainable Behaviour can help here. That’s certainly the aim of what I’m doing.

Interview with Sir Clive

Sir Clive Sinclair (BBC image)Chris Vallance of Radio 4’s excellent iPM has done a thoughtful interview with Sir Clive Sinclair, ranging across many subjects, from personal flying machines to the Asus Eee, and touching on the subject of consumer understanding of technology, and the degree to which the public can engage with it:

Your [Chris Vallance’s] generation really understood the computers, and today’s generation know they’re just a tool, and don’t really get to grips with them… When I was starting in business, and when I was a child, electronics was a huge hobby, and you could buy components on the street and make all sort of things, and people did. But that also has all passed; it’s almost forgotten.

It’s true, of course, that there are still plenty of hobbyist-makers out there, including in disciplines that just weren’t open before, and if anything, initiatives such as Make and Instructables – and indeed the whole free software and open source movements – have helped raise the profile of making, hacking, modding and other democratic innovation. It’s no secret that Clive himself is a proponent of Linux and open source in general for future low-cost computing, as is mentioned briefly in the interview, and the impact of the ZX series in children’s bedrooms (together with BBC Micros at school) was, to some extent, a fantastic constructionist success for a generation in Britain.

But is Clive right? How many schoolkids nowadays make their own radios or burglar alarms or write their own games? When they do, is it a result of enlightened parents or self-directed inquisitiveness? Or are we guilty of applying our own measures of ‘engagement’ with technology? After all, you’re reading something published using WordPress, which was started by a teenager. Personally, I’m extremely optimistic that the future will lead to much greater technological democratisation, and hope to work, wherever possible, to contribute to achieving that.

I’ve worked for Clive, as a designer/engineer, on and off, for a number of years, and it’s pleasing to have an intelligent media interview with him that doesn’t simply regurgitate and chortle over the C5, but instead tries to tap his vision and thoughts on technical society and its future.

Silicon Dreams

Incidentally, Clive’s 1984 speech to the US Congressional Clearinghouse on the Future, mentioned in the interview, is extremely interesting – quite apart from the almost Randian style of some of it – as much as for the mixture of what we might now see as mundanities among the far-sighted vision as for the prophetic clarity, with talk of guided 200mph maglev cars and the colonisation of the galaxy alongside the development of a cellular phone network and companion robots for the elderly. Of course, the future is here, it’s just not evenly distributed yet.

Talk of information technology may be misleading. It is true that one of the features of the coming years is a dramatic fall, perhaps by a factor of 100, in the cost of publishing as video disc technology replaces paper and this may be as significant as the invention of the written word and Caxton’s introduction of movable type.

Talk of information technology confuses an issue – it is used to mean people handling information rather than handling machines and there is little that is fundamental in this. The real revolution which is just starting is one of intelligence. Electronics is replacing man’s mind, just as steam replaced man’s muscle but the replacement of the slight intelligence employed on the production line is only the start.

And then there is this, which seems to predict electronic tagging of offenders:

Consider, for example, the imprisonment of offenders. Unless conducted with a biblical sense of retribution, this procedure attempts to reduce crime by deterrence and containment. It is, though, very expensive and the rate of recidivism lends little support to its curative properties.

Given a national telephone computer net such as I have described briefly, an alternative appears. Less than physically dangerous criminals could be fitted with tiny transporters so that their whereabouts, to a high degree of precision, could he monitored and recorded constantly. Should this raise fears of an Orwellian society we could offer miscreants the alternative of imprisonment. I am confident of the general preference.

Getting someone to do things in a particular order (Part 3)

Continued from part 2

This series is looking at what design techniques/mechanisms are applicable to guiding a user to follow a process or path, performing actions in a specified sequence. The techniques fall roughly into three ‘approaches’. In this post, I’m going to examine the Poka-yoke approach. If you’ve been following the previous posts, you’ll probably have thought, “Well, all that’s pretty obvious.” And it is obvious – we encounter these kinds of design techniques in products and systems every day – but that’s part of the point of this bit of the research: understanding what’s out there already.

Poka-yoke approach

The mechanisms described in this approach are all based on technical (rather than explicitly human) factors, and involve designing the relationships between system elements.

Poka-yoke (Japanese: mistake-proofing) is an approach usually applied in manufacturing engineering, developed by Shigeo Shingo in the context of developing ‘zero defect’ assembly processes. The idea is to avoid slip-type errors by designing systems which prevent them occurring, prevent a user proceeding until the error condition has been rectified (control poka-yokes), or at the very least clearly warn the user of the error condition (warning poka-yokes).

Generally, when the design intent is for the user to follow a process or path in a specified sequence, a deviation from that sequence can be considered as an error, and thus the poka-yoke approach can be applicable outside its original field. Similar concepts, forcing functions, have been developed in interaction design, especially in the work of Donald Norman – the three main forcing function mechanisms, Interlock, Lock-in and Lock-out, broadly correspond to Shingo’s control poka-yoke category; all can help in assisting (or forcing) users to follow a process or sequence. In the warning poka-yoke category, the Arrangement detection mechanism is most relevant to this behaviour.


An Interlock combines elements of both lock-ins and lock-outs (see below), and is probably the most familiar forcing function mechanism: the ability to use one function is dependent on another running or being started, another component (such as a guard) being in place, or some other condition being fulfilled.

Toyota Verso clutch-ignition interlockToyota Verso clutch-ignition interlockToyota Verso clutch-ignition interlock
Example: This Toyota Verso requires the clutch pedal to be depressed before the starter button will operate, to reduce the risk of starting in gear.

Car ignitions which cannot be operated unless the driver’s seat belt is fastened – a system originally promoted as ‘Interlock’ in the US – microwave ovens not operating unless the door is closed, and airline or train toilets where the lighting does not operate until the user has locked the door, are some of the highest profile everyday examples, but the principle of the interlock is extremely common in engineering and manufacturing industry, often in the context of a machine tool which will not start until a guard is in place, or where opening the case automatically cuts the power.

Interlocks are often specified when it is imperative – rather than merely desirable – that a user follow a particular sequence, or at least two steps of a sequence, in exactly the right order, but their use need not be limited to critical safety design problems. Ecodesign applications might include (for example) a car’s air conditioning system requiring the windows to be fully closed before operating, or a sink requiring the plug to be in before the tap can be left in a ‘running’ position.

Microwave oven door interlockMicrowave oven door interlock
Example: The ubiquitous interlock on a microwave oven ensures that the door is closed before the oven will start.


The Lock-in mechanism in this context (rather than an economic one) refers to a system arranged such that a process, procedure or operation is kept active – the user can’t exit the operation until a certain condition is met, or the ‘correct’ next step is taken. This can be implemented using sensors, logic processing, physical architecture, or a number of other ways.

As Norman puts it, this prevents “someone from prematurely stopping” an operation – this could mean letting some ongoing process run its course to completion before starting the next, or denying the user access to another function which might interfere with the current process. It can also prevent accidental cancelling of an operation – inadvertent deviation from a specified sequence – by introducing an extra ‘confirmation’ step.

Confirmation dialogue
Example: The confirmation dialogue displayed by some software when a user attempts to exit can be seen as a lock-in to prevent inadvertent ending of the application.


Lock-out is closely related to Lock-in: in this case, the mechanism makes it difficult or impossible for the user to start certain operations, or denies or impedes access to particular areas or functions. In the context of encouraging or forcing a user to follow a path or process in a specified sequence, a lock-out helps prevent inadvertent or mistaken steps in that sequence. It can also help prevent an operation being started too early in the sequence, and may also be implemented as an extra ‘confirmation’ step.

Lock-out dialogue
Example: This file backup application prevents a user modifying the properties of a scheduled backup task while it is running – ensuring that the correct sequence is followed.

Arrangement detection

Arrangement detection is a ‘warning’ rather than ‘control’ poka-yoke mechanism, and may be considered as a ‘feedback’ analogue of interlocks, lock-ins and lock-outs – providing a warning (audible, visual, tactile) when system elements are incorrectly arranged (physically or procedurally).

Arrangement detection is about warning the user that the path or process is occurring in an incorrect sequence, rather than actually forcing the user to follow the correct sequence. While there are a number of possible warning poka-yoke mechanisms alerting users to incorrect behaviour, arrangement detection is most relevant to the specific issue of sequencing.

Seatbelt warning
Example: The seat belt warning on car dashboards (in this case a Fiat Punto) is an arrangement detection poka-yoke, providing a visual (and often also audible) alert that a belt is not buckled while the engine is running, or the car is moving.

In part 4, we’ll look at the Persuasive Interface approach to getting someone to do things in a particular order.

Getting someone to do things in a particular order (Part 2)

Continued from part 1

Suggested mechanisms

These are the suggested mechanisms applicable to User follows process or path, performing actions in a specified sequence – they fall roughly into three ‘approaches’. In this post, I’m going to examine the System element approach.

System element approach

This approach includes mechanisms relating to the layout and properties of system elements, hence all technical rather than human factors.

Placing, Spacing and Orientation – how system elements are laid out – are some of the most fundamental mechanisms a designer can employ to help a user to follow a process or path in the intended sequence, and can be used both in the ‘real’ world and, as metaphors, in software. Movement or oscillation, as an ‘action’ property of system elements, which may involve changing their placing/spacing/orientation, can also be used to help achieve similar aims.


Placing may be implemented as simply as arranging interactive elements (functions, buttons, shops, products on shelves – effectively, anything) in sequence so that a user interacts (sees / notices / experiences / uses) them in the ‘right’ order. This might involve actually hiding one element behind another so that the first ‘must’ be dealt with before progressing to the next (or only displaying the second element once the first has been dealt with), but often this is not necessary: users will tend to interact with elements in a predictable sequence, at least where it is clear which direction the sequence is meant to progress (compare reading directions in different alphabets, for example, and the effect this has on the layout of interfaces).

Amazon's order process reveals elements in sequence
Example: The elements of Amazon’s order process, revealed to the user in sequence

Placing can also involve arranging (non-interactive) elements to ‘channel’ users along a path in an intended sequence – walls, fences and guard rails are obvious architectural examples, but there are more subtle ones too, such as the layout of some casinos in which winners are ‘funnelled’ past many lures on their way to a single cashier.

Guard rails to channel pedestrians
Example: Guard rails are placed to channel pedestrians away from crossing at the mouth of a road junction


Spacing – deliberate separation of system elements in space – can also be used strategically to cause users to follow a path or sequence of operations or interactions. For example many supermarkets are laid out with common items such as milk and bread at the back of the store, meaning that shoppers pass many other shelves of items (with potential for impulse purchase) on the way to their ‘target’, and on the way back to the checkouts at the front of the store.

Spacing can also be used to cause users to follow procedures requiring a delay between performing operations – the ‘on’ switch for a lathe may be spaced far enough away from the chuck that it is impossible for the operator’s fingers to be in a dangerous position as the device is switched on. Along similar lines, spacing light switches for different parts of a corridor or stairway apart so that they must each be switched on in sequence individually when needed (rather than allowing users to switch them all on at once) may reduce unnecessary electricity use.

Dairy section drives traffic to rear of supermarket
Example: Dairy items are often positioned to drive traffic to the rear of a supermarket. Image from wander.lust


Orientation is necessarily related to placing and spacing – the relative angle or attitude of system elements can be used as a mechanism for encouraging or channelling users to follow a path or perform actions in sequence. A trivial example is the use of angled walls to ‘funnel’ pedestrians along a particular path. It can also be used to cause users themselves to change their orientation in response, where this is part of an intended sequence of user behaviour – the staggered pedestrian crossings which make sure users turn to face the direction of oncoming traffic, as mentioned in Part 1, use the changing orientation of the walkway to change users’ orientation.

Pedestrian crossing staggered to cause users to face oncoming traffic
Example: A staggered pedestrian crossing designed so that users face oncoming traffic. Image from the UK Highway Code.

Movement or oscillation

Movement or oscillation may involve changing the placing/spacing/orientation of system elements, and can be applied in a physical or metaphorical sense. A moving indicator which guides the user through a process or sequence, or indeed, brings system elements which require interaction to the user (or routes them past), encourages (or forces) following procedures in the ‘right’ order.

Consider this mechanism as a dynamic implementation of placing/spacing/orientation: it has the potential to control much more fully the order in which users are exposed to objects or functions. The most obvious examples are conveyors on production lines, bringing components or products to stationary workers in the right sequence, but even museum exhibits such as the Crown Jewels may be displayed in a rotating or constantly moving case, which displays them to visitors in a certain order and reduces the possibility of undesired interactions.

Conveyor brings items to user in the right sequence
Example: A conveyor (such as this on a Krispy Kreme doughnut preparation line) brings products or components to workers in the right sequence. Image from Silversprite

In part 3, we’ll look at the Poka-yoke approach to getting someone to do things in a particular order.