Jamie Bullock

A set of rules on clear, straightforward writing from George Orwell’s essay Politics and the English Language.

1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
2. Never use a long word where a short one will do.
3. If it is possible to cut a word out, always cut it out.
4. Never use the passive where you can use the active.
5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
6. Break any of these rules sooner than say anything outright barbarous.

I love the concise writing style implied by these rules, but I particularly like rule 6. One problem I find with my own writing is that it can tend to be over-concise; too many words cut out, not enough explanation. Rule 6 asks writers to use the other rules as guidelines and always to use their own judgement. The full essay is well worth a read.

Thanks to @davidortinau for the link.

For my next project, I’m going to try the following software development method:

This draws upon elements of Test Driven Development and Spiral Model but tries to be lighter-weight. Requirements gathering is eschewed in favour of domain expertise. The screencast building and documentation process is used as a springboard for mockups and graphic designs, and to force user interaction think-through prior to coding.

Any thoughts?

Let’s start by making one thing clear: I’ve never been a huge fan of Adobe’s Flash. It always seemed to me, a necessary evil — necessary because it allows publishing on the web that can’t be done with the browser alone, and evil because it requires the installation extra software to access content.

But in the light of recent criticism from Apple, I find myself becoming concerned about the misleading way arguments are being presented. The main reason for this is that Apple’s criticism of Flash, and promotion of HTML5 seems primarily a piece of market positioning: Apple, the champions of open standards, Adobe, the peddlers of all that is closed and proprietary.

Why would Apple do this?

Well, what the Flash vs HTML5 debate does is to hide the real reason for Apple’s anti-Adobe position: Apple wants to control the web publishing abstraction layer. Specifcally, this isn’t really about Adobe at all, this is about any non-Apple software for developing content and applications on the web. Apple isn’t just anti-Flash, they’re anti-Java and anti- anyone else who wants to provide abstraction from the browser and alternative browser-based development platforms. In short, Apple wants WebKit to be your one-stop shop for web publishing on any device.

In theory this seems like a good thing, developers and designers could have one publishing platform, and one set of standards (HTML5 + CSS + JavaScript) all running under a cleanly designed layout engine developed by one of the best software shops in the world and it would look and feel the same wherever they deployed it. To top this, WebKit is even open source. This is why it is gaining traction and now used not just in Apple’s Safari browser, but also in Google’s Chrome, Gnome’s Epiphany and on a large number of mobile devices .

So what are the implications of this? Well, currently if you want your content or app to look and feel exactly the same regardless of browser, you develop in Flash. Flash provides an abstraction layer that isolates the your code from cross-browser differences and incompatibilities. Apple want’s to kill Flash and for WebKit to become the abstraction layer; it wants WebKit not Flash to isolate your code from cross-browser differences. In Apple’s world, Webkit will become the layout engine.

The problem with all of this is that by controlling the publishing abstraction layer, Apple is effectively controlling the type and nature of the content you can publish online. This is the opposite philosophy to the early evolution of the web and browser technology. Instead of being de-centralised and community driven, it looks like the future of the web will be centralised and driven by a few big companies, like Apple and Google.

I leave the reader to decide if all of this is a good thing, but end with the closing thought that the primary aim of big companies it to make money for their shareholders. Apple are not the champions of open standards Steve Jobbs makes them out to be, neither are Adobe evil purveyors of everything closed-source and proprietary. Both companies are open so far as it suits them and only where it means greater control in the marketplace and gain in market advantage.

A couple of years ago I was involved in starting a software development project that aimed to bring a focus of usability, good user experience and ‘feel good’ graphic design to open source music creation software. We were discussing potential platforms one day, and my boss suddenly said to me “we should use Ruby”! I was a little taken aback by this. I had been aware of Ruby as a scripting frontend for the Gnome desktop environment, but not as a serious desktop application development language. So why did he suggest it? Well, if you look around at software on the web that has great UI and UX, and great look and feel, Ruby is never far away. In short, people who understand and appreciate great design are attracted to Ruby, and these people employ great designers.

The Ruby official site is a case in point. It has a nice succinct paragraph telling you what the language is about, set against a simple code example, easy and prominent links to download and get started and a cuddly look ‘n’ feel that makes you want to dive in and get coding. Following the “Success Stories” link, we see that Ruby is used by ‘A List Apart’ and 37Signals; notable gurus of web design and purveyors of good taste.

The Python home page by comparison looks cluttered, and has a clunky opening paragraph. The look ‘n’ feel is clinical and lifeless with no space for the content to ‘breath’. Python’s ‘Success stories’ section is harder to find and more verbose and poorly presented. In short, from the respective websites alone, Python comes across as a less-appealing, less-sexy language than Ruby.

Compare also Ruby on Rails (arguably Ruby’s flagship success story) to other web development frameworks in terms of their marketing:

• Ruby on Rails (Ruby)
• Django (Python)
• CakePHP (PHP)
• Catalyst (Perl)

For me the Rails site just gets it right: it’s clear, concise, elegant and exciting. In terms of design, the other frameworks don’t come close.

So… I can see why someone who wants to make a piece of software with focus on usability and great design, might choose Ruby: it has a community of like-minded people around it, all pushing out nicely designed web apps. This isn’t about band-wagon jumping or being a ‘victim’ of marketing or hype, it’s about acknowledging that talent converges around great design. Python, Lua et al, might be well designed languages, they may well be more powerful, more readable or more flexible than Ruby, but if they can’t convey this effectively through their web presence, they won’t attract developers who value great design.

We spend a lot of time complaining about live electronic music — the unreliable systems — the complex setups — the unappreciative audiences, performers, composers — the poor documentation — the lack of standards — the lack of a good business model.

Nothing ever seems to work first time. For every piece and every concert we have to painstakingly decipher the work of the original creators in order to unravel some mysterious problem. We untangle cables and untangle code, we restart, rewire and reconfigure until everything works.

But the truth is, when all of the preparation is done, when the problems are solved, when the mixing desk is in place and the speakers are on. When the levels are up and the score is open, when you sit facing the performer and the audience is ready, when the lights are dimmed and the atmosphere is charged; ready for the first note… there’s nothing quite like the ‘buzz’ of live electronics.

Happy New Year! In an attempt to encourage myself to keep them, I thought I’d blog my new year’s resolutions. Here they are:

• Give less, do more

This will be the year I give up my long standing Greenpeace donation as well as donations to NSPCC and Cancer research. I feel kinda bad about this, having been a Greenpeace member for over 10 years. I didn’t take the decision lightly, but I now have three children and am considering starting a business - things will be tight. Equally I’m starting to feel that a lot can be achieved through direct action, and there are many other contributions I can make that are not financial. I therefore intend to do more letter writing and campaigning this year. I might even get my conservation volunteering boots back on.

• Grow my own

Growing your own veg seems to me a complete win. It’s good for the environment, it’s rewarding, it’s good for you and it tastes great. I’ve never had a proper garden, but this year I have no excuse. Considering also buying a greenhouse.

• Work smarter, not harder

There is a lot I want to do with my life, and at the moment I’m nowhere near getting it done. If I try to physically do everything myself, I’ll never get there. This year I’m going to step back and delegate more. I’m going to focus on the areas where my skills can add the most value.

• Read a book per week

This may sound ambitious, but I’m going to try to read an average of one book per week. I have way too many unread books sitting at work and at home. Time to read them or stop buying books.

• Relax and play

2009 was kinda crazy. I submitted my PhD and viva’d in March; my wife gave birth to twins in April, making us a family of five; we bought a house and moved in August. All of this whilst managing a European software development project, coding, writing papers and running a number of side projects. Towards Christmas, I was starting to feel a strong sense of burnout. So… in 2010 I need to set aside specific relaxation times in my weekly routine. These can be used for meditation, reading for pleasure or creative play etc.

My overall theme of the year is ‘flow’. The plan is that by doing less in some areas, I can achieve more in the aspects of my life that are most important to me. Let’s see what happens!

My latest offering on Mixcloud — variations on the jazz standard, Caravan.

The blogosphere is currently alive with talk of the new Eigenharp from eigenlabs, officially released earlier this week. The Eigenharp, which comes in two forms, a large “Eighenharp Alpha” (pictured below) costing from £3,950 and a small “Eigenharp Pico” from £349 is described by eigenlabs as

“the most revolutionary new musical instrument of the last 60 years […] Designed specifically for live performance, it is simply the most expressive electronic musical instrument ever made.”

Now this claim has got me kind of annoyed. Not because I think the design is bad, or that it isn’t a great product, but because the Eigenharp isn’t a musical instrument at all, it’s just a controller. It’s a device a performer can use to produce a stream of information that could be used to trigger or control the synthesis of sound. However the Eigenharp itself however, doesn’t produce sound, and in fact once eigenlabs open source their software the Eigenharp could be used to control pretty much any electronic device . It is no more a musical instrument than a Wacom graphics tablet, an iPhone or any other device that can emit control data that when mapped correctly can be used to synthesise sound.

This might sound like a pedantic distinction, but it is very, very important in understanding what makes something a musical instrument. The instrument isn’t just about the physical interface, but rather the combination of a number of elements working together:

• the physical body of the instrument
• the human-mechanical interface
• the sound-producing mechanism

Traditionally musical instruments have a range of sound qualities (timbre) and a largely deterministic sound response in relation to human interaction. This makes them interesting and identifiable as being one specific instrument or another. Examples of instruments or devices with instrument-like capabilities include:

• a flute
• an electric guitar played through a Marshall amp (the combination of the guitar and the amplification form the instrument in this case)
• a zero input mixing desk
• a minimoog synth

All of the above have identifying sonic traits and models of interaction. The Eigenharp provides a interface with for the performer to interact with… so what of the sound production? Well, from the eigenlabs website:

“You can load and play your own Soundfonts, Audio Unit Plugins and Midi instruments with the Eigenharp Alpha. In addition, the Alpha comes with its own native instruments (at present a software model of a Cello, Clarinet and a Synth engine). The Alpha also ships with a collection of loop libraries and several acclaimed instruments from our partners:”

So basically, the Eigenharp could sound like anything — it is just a controller, it may be an excellent controller (I’m not sure), but it is only a controller — not a musical instrument.

Which brings me to the main point of this post. We really need to move beyond the controller-centred approach to ‘instrument design’, and start thinking about what it is that we are controlling, and what the complete interaction model is. By this, I mean that we need to design for the complete sensory experience of the performer when they play an instrument, not just physical control. The complete ‘feedback loop’ might include:

• physical input
• physical response (in the form of vibration e.g. through the fingertips)
• sound production
• physical stimulus (in the form of sound from the instrument)
• (adjusted) physical input in response to audio/visual cues

All of these elements interact in complex ways to form the performer-instrument relationship. However, if we focus too heavily on the design of one element (the controller, or the sound), we end up producing not an instrument, but a system that gives the illusion of being an instrument.

I’m kind of obsessed by the Jazz Standard, ‘Round Midnight by Thelonious Monk. I performed it for my first year Piano exam at University, and have kept revisiting it ever since. The harmony and and phrasing is enchanting and lends to many interpretations. This mix on mixcloud includes some of the choicest picks. I think the Wes Montgomery take is my favourite.

'Round Midnight by Outoftune.Tv on Mixcloud

The following Google calendar represents the list of BBC Proms 2009 concerts containing ‘modern’ works. Based on a list originally compiled by Ed Lawes that can be found here.

Click individual concert links to see full programme listings.

An iCal file containing the above calendar can be downloaded here.

Enjoy!