A couple of months back I visited Tom and Durrell at Luckybite to discuss some of the Olinda development. During our conversation, Durrell described one of his favourite portable radios, the Bang & Olufsen Beolit 600. I bought one.

The range was produced between 1971 and 1981 and aside from its elegance and good audio quality, the detailing is very deft.

Tuning with magnets

The chassis is constructed from aluminium strips, holding plastic shells front and back. The controls for the radio are spread out along the front and back edges of the top face. On the back edge are buttons for band selection and two sliders for volume and tone. The entire front edge is a horizontal tuning slider.

The slider can be grabbed and pushed quickly up and down the length for coarse tuning. To tune precisely the two small kinked wheels are rolled under the thumb to give fine control. The remarkable detail is in how the selected frequency is indicated:

Two very small steel bearings sit in covered grooves in the aluminium chassis, one for each tuning band. The tuning slider conceals a magnet, which drags the bearings along the scale inside their grooves (the aluminium is of course unaffected by the magnetism). The position of the bearings corresponds to markings on the surface of the radio which indicates the frequency the radio is tuned to.

It’s a really nice example of celebrating functionality. There is no functional need for the bearings. The additional cost to develop and manufacture can’t possibly have made financial sense. Why not use an arrow? But tuning is what radios do, and something which articulates this most familiar function so poetically just had to be done.

I love how the furthest bearing twitches along more slowly than the closer one.

Construction

Structurally the radio is a square of four lengths of extruded and cut aluminium, with the front and back plastic shells tucked in. What’s exciting is that taking the radio apart isn’t work: there are no machine screws or self-tappers.

The base plate of the radio can slide. Sliding it a little way first unlocks the back shell. Removing the back allows the base to slide more, which releases the more rarely removed front shell. All this is achieved with a clever system of grooves and nooks.

Coming off first, the back shell gives access to the battery. The front shell reveals something else.

The repair manual

Inside the front shell, there is a little envelope. Inside the envelope there is a piece of folded paper.

Screen printed on the paper are all the instructions for repairing the radio. There is an abstracted circuit diagram and also an image of the actual PCB. The radio contains its own data sheet, physically!

I’ve cut these last two images together to show that the PCB and the print in the diagram are to scale (the screens were probably made from the same drawing).

One of Olinda’s jobs is to communicate the potential for hardware APIs. Matt discussed this in detail in his post on widgets.

Olinda is expandable and modular. For this to be effective, the core services of the central unit really have to be accessible from it’s periphery. We don’t mean superficial expansion or extension of lineout (like adding a speaker), but actually change the nature of the object, to grow from it’s core. There is an obvious predecessor in consumer electronics in hi-fi separates, although it is limited in that the turntable cannot affect the services available through the interface, on the amplifier. The extensions for Olinda will be able to make the radio a new object with each addition (In our case main and social do this).

Part of this project is to discuss modularity. (While designing the physical radio itself is a large part of the work, the larger project is about communicating the core ideas.) The connector is effectively a serial connection between the main unit and the extensions (plus a few extras). This could have manifested as a serial cable with two sockets on each unit, much as they appear on old printers and the like. Although traditional connections and cables have historical precedent, they do not sufficiently raise modularity.

We were clear early that the mechanism for connection should be visible, rather than discreet. It should go out of its way to invite extension (Matt discusses these ideas with reference to the Levittown Homes in his talk, The Experience Stack). One should see how it extends and the connection be mechanically explicit. The use of the mechanism, the act of extending should feel really satisfying too. For the reasons described above the serial cable fails.

Connector developments

Each module needs to include a surface which connects to the previous. Software and power aside, the implication should be that the units are infinitely extensible. To begin with we examined the possibility of a mechanical connection, something with toggle clamps or vertical stacking.

Kiyoshi Seike’s book on Japanese joinery includes some beautiful imagery, above.

In some early work we experimented with connections in wood. As the process progressed and more influences on the form of the radio emerged, we chose to explore a system of magnets and studs. This delivered the most satisfying feeling and the building brick aesthetic taps nicely into the familiar heritage of Lego.

This idea came out of both Apple’s MagSafe power connector, and a previous project on RFID which touched on using magnets for tactile feedback to make reading RFIDs more like pressing a button

So in the final model, the entire end surfaces of the modules are positive and negative connectors.

These two images show the progression of the studs, looking for a good fit and a good feel. These models also explore how the magnets are to be included.

There are eight electrical connections between the modules. These are a line of sprung copper domes, held against copper blanks on the opposite face by the force of the magnets.

Above is the most recent and final connectors prototype before machining, and the image following gives an impression of the final form.

Much of the early work in this process was produced with the help of Jeff Easter, thanks Jeff!

Last week, Tristan Ferne who leads the R&D team in BBC Audio & Music Interactive gave a talk at Radio at the Edge (written up in Radio Today). As a part of his talk he discussed progress on Olinda.

Most of the design and conceptual work for the radio is finished now. We are dealing with the remaining technicalities of bringing the radio into the world. To aid Tristan’s presentation we drew up some slides outlining how we expect the core functionality to work when the radio manifests.

Social module

This animated sequence shows how the social module is expected to work. The radio begins tuned to BBC Radio 2. A light corresponding to Matt’s radio lights up on the social module. When the lit button is pressed, the top screen reveals Matt is listening to Radio 6 Music, which is selected and the radio retunes to that station.

Tuning

This detail shows how the list management will work. The radio has a dual rotary dial for tuning between the different DAB stations. The outer dial cycles through the full list of all the stations the radio has successfully scanned for. The inner dial filters the list down and cycles through the top five most listened to stations. We’ll write more on why we’ve made these choices when the radio is finished.

Earlier this year we hosted a workshop for Timo Arnall’s Touch project. This was a continuation of the brief I set my students late last year, to design an icon or series of icons to communicate the use of RFID technology publicly. The students who took on the work wholeheartedly delivered some early results which I summarised here.

This next stage of the project involved developing the original responses to the brief into a small number of icons to be tested, by Nokia, with a pool of 25 participants to discover their responses. Eventually these icons could end up in use on RFID-enabled surfaces, such as mobile phones, gates, and tills.

Timo and I spent an intense day working with Alex Jarvis and Mark Williams. The intention for the day was to leave us with a series of images which could be used to test responses. The images needed consistency and fairly conservative limits were placed on what should be produced. Timo’s post on the workshop includes a good list of references and detailed outline of the requirements for the day.

I’m going to discuss two of the paths I was most involved with. The first is around how the imagery and icons can represent fields we imagine are present in RFID technology.

Four sketches exploring the presence of an RFID field

The following four sketches are initial ideas designed to explore how representation of fields can help imply the potential use of RFID. The images will evolve into the worked-up icons to be tested by Nokia, so the explorations are based around mobile phones.

I’m not talking about what is actually happening with the electromagnetic field induction and so forth. These explorations are about building on the idea of what might be happening and seeing what imagery can emerge to support communication.

The first sketch uses the pattern of the field to represent that information is being transferred.

The two sketches below imply the completion of the communication by repeating the shape or symbol in the mind or face of the target. The sketch on the left uses the edge of the field (made of triangles) to indicate that data is being carried.

I like this final of the four sketches, below, which attempts to deal with two objects exchanging an idea. It is really over complex and looks a bit illuminati, but I’d love to explore this all more and see where it leads.

Simplifying and working-up the sketches into icons

For the purposes of our testing, these sketches were attempting too much too early so we remained focused on more abstract imagery and how that might be integrated into the icons we had developed so far. The sketch below uses the texture of the field to show the communication.

Retaining the mingling fields, these sketches became icons. Both of the results below imply interference and the meeting of fields, but they are also burdened by seeming atomic, or planet sized and a annoyingly (but perhaps appropriately) like credit card logos. Although I really like the imagery that emerges, I’m not sure how much it is doing to help think about what is actually happening.

Representing purchasing via RFID, as icons

While the first path was for icons simply to represent RFID being available, the second path was specifically about the development of icons to show RFID used for making a purchase (’purchase’ is one of the several RFID verbs from the original brief).

There is something odd about using RFID tags. They leave you feeling uncertain, and distanced from the exchange or instruction. When passing an automated mechanical (pre-RFID) ticket barrier, or using a coin operated machine, the time the machines take to respond feels closely related to the mechanism required to trigger it. Because RFID is so invisible, any timings or response feels arbitrary. When turning a key in a lock, this actually releases the door. When waving an RFID keyfob at reader pad, one is setting off a hidden computational process which will eventually lead to a mechanical unlocking of the door.

Given the secretive nature of RFID, our approach to download icons that emerged was based on the next image, originally commissioned from me by Matt for a talk a couple of years ago. It struck me as very like using an RFID enabled phone. The phone has a secret system for pressing secret buttons that you yourself can’t push.

Many of the verbs we are examining, like purchase, download or open, communicate really well through hands. The idea of representing RFID behaviours through images of hands emerging from phones performing actions has a great deal of potential. Part of the strength of the following images comes from the familiarity of the mobile phone as an icon–it side-steps some of the problems faced in attempting to represent an RFID directly.

The following sketches deal with purchase between two phones.

Below are the two final icons that will go for testing. There is some ambiguity about whether coins are being taken or given, and I’m pleased that we managed to get something this unusual and bizarre into the testing process.

Alex submitted a poster for his degree work, representing all the material for testing from the workshop:

The intention is to continue iterations and build upon this work once the material has been tested (along with other icons). As another direction, I’d like to take these icons and make them situated, perhaps for particular malls or particular interfaces, integrating with the physical environment and language of specific machines.

Last term during an interim crit, I saw the work my students had produced on the RFID icons brief I set some weeks ago. It was a good afternoon and we were lucky enough to have Timo Arnall from the Touch project and Younghee Jung from Nokia Japan join us and contribute to the discussion. All the students attending showed good work of a high standard, overall it was very rewarding.

I’ll write a more detailed discussion on the results of the work when the brief ends, but I suspect there may be more than I can fit into a single post, so I wanted to point at some of the work that has emerged so far.

All the work here is from Alex Jarvis and Mark Williams.

Alex began by looking at the physical act of swiping your phone or card over a reader. The symbol he developed was based on his observations of people slapping their Oyster wallets down as they pass through the gates on to the underground. Not a delicate, patient hover over the yellow disc, but a casual thud, expectant wait for the barrier to open, then a lurching acceleration through to the other side before the gates violently spasm shut.

More developed sketches here…

I suspect that this inverted tick will abstract really well, I like the thin line on the more developed version snapping the path of the card into 3D. It succeeds since it doesn’t worry too much about working as an instruction and concentrates more on a powerful cross-system icon to be consistently recognisable.

Verbs

The original brief required students to develop icons for the verbs: purchase, identify, enter (but one way), download, phone and destroy.

Purchase and destroy are the two of these verbs with the most far-reaching and less immediate consequences. The aspiration for this work is to make the interaction feel like a purchase, not a touch that triggers a purchase. This gives the interaction room to grow into the more complex ones that will be needed in the future.

This first sketch, on purchase, from Alex shows your stack of coins depleting, something nice about the dark black arrow which repeats as a feature throughout Alex’s developments.

Mark has also been tackling purchase, his sketches tap into the currency symbols, again with a view to represent depletion. Such a blunt representation is attractive, it shouts “this will erode your currency!”

Mark explores some more on purchase here:

Purchase is really important. I can’t think of a system other than Oyster that takes your money so ambiguously. Most purchasing systems require you to enter pin numbers, sign things, swipe cards etc, all really clear unambiguous acts. All you have to do is wave at an Oyster reader and it costs you £2… maybe: The same act will open the barrier for free if you have a travel card on there. Granted, passengers have already made a purchase to put the money on the card, but if Transport for London do want to extend their system for use as a digital wallet they will need to tackle this ambiguity.

Both Mark and Alex produced material looking at the symbols to represent destroy, for instances where swiping the reader would obliterate data on it, or render it useless. This might also serve as a warning for areas where RFID tags were prone to damage.

I like the pencil drawing to the top right that he didn’t take forward. I’ve adjusted the contrast over it to draw out some more detail. Important that he distinguished between representing the destruction of the object and the data or contents.

Mark’s sketches for destroy include the excellent mushroom cloud, but he also looks at an abstraction of data disassembly, almost looks like the individual bits of data are floating off into oblivion. Not completely successful since it also reminds me of broadcasting Wonka bars in Charlie and the Chocolate Factory and teleporting in Star Trek, but nice none the less.

Drawing

This is difficult to show online, but Alex works with a real pen, at scale. He is seeing the material he’s developing at the same size it will be read at. Each mark he makes he is seeing and responding to as he makes it.

He has produced some material with Illustrator, but it lacked any of the impact his drawings brought to the icons. Drawing with a pen really helps avoid the Adobe poisoning that comes from Illustrator defaults and the complexities of working out of scale with the zoom tool (you can almost smell the 1pt line widths and the 4.2333 mm radius on the corners of the rounded rectangle tool). It forces him to choose every line and width and understand the success and failures that come with those choices. Illustrator does so much for you it barely leaves you with any unique agency at all.

It is interesting to compare the students’ two approaches. Alex works bluntly with bold weighty lines and stubby arrows portraying actual things moving or downloading. Mark tends towards more sophisticated representations and abstractions, and mini comic strips in a single icon. Lightness of touch and branching paths of exploration are his preference.

More to come from both students and I’ll also post some of my own efforts in this area.

There’s been rather an explosion of desktop, mobile, browser and Web widgets. Recently, too, I was groping round the idea of web apps situated outside the computer–but not getting very far. Then I was chatting over email about the Chumby, a cute, carryable, dedicated widget platform… and situated web apps ideas finally locked into focus:

Widgets embedded in everything.

My camera, video camera, phone, mp3 player, TV, DVD player and car stereo all have embedded electronics, a control surface and a display. My washing machine and oven have micro-controllers and an interface–I don’t know whether my house thermostat is electronic, but it could be.

In short: I am surrounded by objects which do things, all with embedded computing and screens. What if I could run whatever applications I wanted to on them? What if, let’s say, each of them was a widget platform, allowing code upload and exposing a hardware API to all sensors and controls?

Hardware as an open platform

If I was a pro-am photographer on a month-long safari shoot, I could grab a custom camera interface from the Web, set up to provide easy-access presets to the light and movement conditions I’d face. I’d repurpose a couple of the external buttons to twiddle parameters in the presets, and have a perfect wildlife interface for four weeks. At home, I’d revert to the general purpose interface or get another one.

If I could sell widgets for compact cameras, I’d sell one that was specially made for nights out. It’d assess the conditions and get the best possible picture given the dark, the necessity of taking a quick shot, and the inability of the drunk person holding the camera to stop swaying.

I’d have an interface on my washing machine that had only the single setting I use. I’d load and set the machine early in the morning or late at night, and it’d then display a red, flashing “ready to go” button that I could slap on my way out of the house, after my morning shower. Perhaps it would use the hardware API to the pressure on the water intake, to refuse to start if the shower was in use.

My TV would use its video buffer and the remote control API to give me a dedicated “record this advert” button.

Hey, maybe I’d even hack my vacuum cleaner and have it fight.

Why can’t I write widgets to run on everything in my pockets and everything in my home? I don’t really mean home automation–I mean using the existing control surface to interface with the hardware in a way that I chose.

I want to download widgets off the Web, scan barcodes with my oven to share recipes with my friends on last.microwave, and hard-code my radio to never miss Radio 4 comedy. This is what I mean about 3C products tapping into creativity, community and connectedness, by the way.

What Nikon should do

Professional Nikon cameras aren’t doing so well against Canon right now. If I were Nikon, I’d document the hardware API to the camera files, the jacks, the display and the controls, stick Bluetooth in it, and throw the camera open as a software platform. Then as a professional purchaser, I’d have a significant decision to make: Do I put down a year’s purchasing power on a Canon, and risk having a Nikon-owning competitor later creating an interface that makes them twice as effective… or get a Nikon so I never get left behind?

Embedded widgets are already here

We already have widgets in some things, of course. My Nokia N70 runs Python, which now has the ability to intercept and send SMS, run full-screen apps, and is provided with APIs to the camera, calendar, contacts, the internet and more. That the small Python app can bridge the hardware API with all the other APIs on the internet, using the existing display and keys, is what makes this so powerful.

Here’s another data-point: The Canon imageRunner series of networked copier/scanner/printers have what they call Java MEAP: A platform to write and run your own apps on the copier. (Thanks Simon Wardley for alerting me.) As this MEAP interview says:

It’s not so difficult to include a variety of useful functions in an application so that anyone can use it. Yet, as user requirements vary widely, the application becomes bloated, impairing its operability. … Users can replace the applications as their needs change and enjoy simple operation.

Exactly. Products made for everyone are complex! Let all of us help out to design them just for our friends. Canon’s doing it for workaday, now give me everyday.

I’m currently reading Dan Saffer’s Designing for Interaction. Well written, well structured; a good introduction to interaction design that’s centred on the web as far as I’ve read, and looks as though it’ll take a broader approach in the second half of the book. This passage, on icons, grabbed me:

A confusing image can obscure much more than it can illuminate. For example, the disk icon has come to mean “save,” even though, increasingly, many young people have never seen a floppy disk (except perhaps this icon!). Then again, it is difficult to imagine what image could replace it.

Well that’s a challenge if ever there was one.

People don’t use paper files like they use to, and besides, computers aren’t office focused but for the home now. And at home, it’s all about the media.

Could play, pause and the rest replace save and open?

We might have to twist the metaphors a little, but consider the regular set of icons (and I’m sure I’m only thinking of this because I’ve been reading about early play and record icons; more).

How about this: On file open dialogs, the play icon would replace the open button. On toolbars, the play icon would be used to trigger the dialog. To close a document, saving automatically, the pause icon would be shown.

The metaphor here is that a document is a continually evolving piece of media. There’s no concept of “save,” what you see on the screen is what’s on the disk. You can never lose work. Play and pause simply mean start and suspend editing.

Ah, but what if you wanted a safe and stable version of your document to always come back to? That’s what the record icon would be for. It’d be analogous to “save as,” kinda, but a better description would be that record means “tag this as stable” in version control. You’d still have your continually evolving document, only the recorded one would be tagged as a version to rely on–an inflection point. This would tie nicely into Apple’s Time Machine, which will let you leaf through previous versions of your files–maybe rewind and fast-forward could be used to step between stable versions.

When I had a dual cassette player, years ago, the second tape deck had a record button for deck to deck dubbing. It only worked if the first was playing. The record button, in our new system, could also be attached as a label any place the currently playing document could be channelled. So record would also show up next to the printer, to dub the open document to paper, and it’d be on the email application, and next to IM buddy names too… it’s a bit of a stretch, this one, but I’d like to try it.

Naturally stop would send your document to the trash.

This change in metaphor, from document as a discrete thing to something which is continuously changing, would affect much of the desktop GUI. Rather than an application which has the command “send to printer,” it has to be a representation of your printer which has the record button on it.

And what does “now playing” mean, given our computers multitask? Perhaps it’s a good thing for us to think of them playing documents over one-another, in a cacophony. It means we’d start thinking about which we focus on, and how to quieten the others–would we have a “stifle” button, to suppress alerts from playing documents that aren’t at the pinnacle of our focus?

Documents as music. What else could replace the disk picture on the open button?