Music Does Not Commute

Hey Guitarists

You know about open string harmonics, right? How you can lightly touch say the bottom E string in the region of the 12th fret (the one just right of the two dots in this Wikipedia diagram), and plucking it, obtain a curiously muted octave note? Somehow softer in timbre than actually playing the fret in the usual way, but unmistakably the same note. That's because the 12th fret is positioned at a point exactly half way up the length of the string, so playing it has the same result, in audio frequency terms, as exciting the string's second harmonic (the red curve marked 2), aka its first overtone, using the light touch trick.

Of course, I'm ignoring the slight stretching of the string caused by pushing it down and on to the fingerboard. So far, so good. And you probably know about the 5th and 7th fret tricks too, right? How the node at the 5th (yellow curve 4) gives you another E, yet another octave up. And how the 7th (orange 3) rings out with a perfect fifth B, this time one octave up from the result of actually playing that fret in the usual way?

Wrong!

Actually those nodes do work as advertised, and the harmonics they produce are just perfect octaves and fifths. However, they are not positioned above the 5th and 7th frets. Because western semitones, specifically the 12 frets in a guitar octave or the 12 keys in a keyboard one, are evenly tempered, i.e., distributed in frequency terms, everything else - everything that isn't an interval of one or more octaves - is just an approximation.

Let's see why. If the perfect fifth interval between E and B corresponded to exactly seven frets, and we strung together twelve such intervals, then we should end up a total of...

7 frets in an interval × 12 intervals = 84 frets

above our starting point, corresponding to a leap of seven octaves:

12 frets in an octave × 7 octaves = 84 frets.

Incidentally, if you find it difficult as I do to imagine a design for a guitar with 84 frets, you might find it helpful to switch to a piano analogy at this point...

Pythagorean Commas

Now consider the sum harmonically. Each perfect fifth interval, say from E up to B, represents a 50% increase in frequency. In other words, the B note, expressed in Hertz (cycles per second), is 1½ times the value of the E. String together twelve such intervals, and you have a frequency multiplication factor of

(3/2) ^ 12 = 3^12 ÷ 2^12 = 531441 ÷ 4096 = 129.75

to two decimal places. That's quite different from the expected value for seven octaves,

2^7 = 128.00

This difference is known as the Pythagorean Comma, and works out at about 1.36%. The implication is that western music, as rendered on guitars and pianos anyway, is not mathematically commutative! We use that seventh evenly tempered fret, or key, as a perfect fifth interval. But if twelve such intervals (12×7 semitones) amount to something different from seven octaves (7×12 semitones), then something has to give. Because it just doesn't add up. Or rather, divide out. To unity.

From Wikipedia: http://en.wikipedia.org/wiki/Pythagorean_comma

I'd always thought the convenient approximations, introduced by even temperament into western music, started way up in the blues-baroque fighting area of disputed flat-sharp sevenths, and extended beyond. Once I'd started thinking a bit more about it - the question that actually occurred to me was wait a minute, how can the seventh power of the twelfth root of two be rational? - I was surprised, the loyal old seventh fret should turn out to be such a liar. Actually in his case, the discrepancy is only of the order of a tenth of one percent. But still!

perfect fifth = 3÷2
seventh fret = 2 ^ (7÷12)
perfect fifth ÷ seventh fret = 1.0011298906275257736

Historical Note (heh)

Prior to being written about by me, the calculation of the Pythagorean Comma was also documented in the Chinese (Han dynasty, 122 BC) philosophical classic work The Huainanzi, subsequently extended by Jing Fang (50 BC), then agonized over by centuries' worth of frustrated piano tuners. It gets its contemporary name from its description in The Division of the Canon, an ancient Pythagorean treatise on the relationship between mathematics and acoustics.

Streamed Music Services

Best In Show

The Register Hardware today published a snapshot comparison table showing how a dozen streaming music services compare to each other. Now, a table is a very fine thing indeed, and a reliable statistician's friend. But you and I prefer pictures, right? So I decided to analyse the data provided, using my own personal and completely arbitrary criteria for preferences and priorities. The aim was to reduce each service evaluation to a single number, and so rank them to help decide which I should select - when the day arrives, and I step over my own cold corpse, to sign and pay up for online music. Spoiler: Deezer wins.

Explanatory note: I do pay for music: offline music. Physical media, which I then own, and don't lease from anyone.

How They're Ranked

Okay, so you're a typical streaming music box. How do you earn my favour?

Well, you start from your base score, which is just the number of tracks offered by your service, in millions. So for example at today's levels, Xbox Music leads the field at this stage with 30, while Spotify and Last.fm currently trail on 18 and 12 respectively. Then, you try to earn bonuses.

The first available bonus, 10%, is for services supported on both web and desktop app platforms. If you have only an app, or only web support, you get zut.

Secondly, we look at mobile support. Almost everyone supports Android and iOS. But Rara is Android only, while the iOS offering by Grooveshark requires a jailbreak, and those by Samsung and Xbox are not quite ready yet, so they lose 10%. Conversely, services offering additional mobile coverage, such as BlackBerry, Palm, Symbian, WebOS and/or Windows Phone, get a token 5% bonus for trying a little harder. Similarly for those with additional, non-mobile platforms such as smart TVs, cable, or non-native game consoles.

You don't have an offline mode? Sorry, that's a 10% tax. My advice to you would be shut up and accept this, the appeal court will only double it to punish your insolence. Why shouldn't I be able to hear the music I've paid for, it will say, on my frequent hiking trips to Dunnet Head?

Finally, there's your price. I regard a standard (non-premium) monthly subscription of £5 as quite reasonable for an unlimited, on-demand, streamed music service. If you disagree (Samsung, Xbox) then help yourself to a 50% kick in the nuts. If on the other hand you think £5 is too much (Deezer, Grooveshark, Last.fm) here's a free cuddly toy and a 25% boost for your awesomeness.

For future reference: I'm likely to introduce a massive penalty for Facebook buy-in. Please, just stop it, all of you.

The Results

La France-based Deezer is my surprise winner, scoring over 26; Spotify the more predictable second, at just shy of 19. Then there's little to choose between Grooveshark, Napster, Pure Music, Rdio and Sony. And, it has to be said, what a thoroughly unimpressive lot they all are!

Ribbon Principles

Just Say No

This is a follow-up to my previous article on the Microsoft Office 2007 ribbon style of user interface (UI). It's prompted by a too-long history of design meetings where apparently everything must be reset to a previous decade, and where new people drop in to ask the same fundamental questions yet again, proposing top-of-the-head suggestions that have already been comprehensively discounted by thorough and painstaking research. A blank slate isn't always the best point of departure.

I've listed a very few, key takeaways from Jensen Harris's presentation on the history and evolution of the ribbon UI. The technology is well matured by now, and these caveats, or something like them (preferably a smallish superset), need to become integral to the our new jumping-off point.

No to the Ribbon (sometimes)

The ribbon was never just a fad to be copied, for the sake of looking like Office 2007. For many applications, those containing a few dozen operations, the menu and toolbar approach is still superior - and using a ribbon just looks silly. It's only when you migrate closer to the region of 50, 100 or more unique user-executable commands, that you should be thinking of switching to this more fluent alternative. Remember, Microsoft were driven to develop this UI by the sheer, exponentially, ever-increasing bloat in the numbers of nested menus, toolbars and task panes, in Office 2003 and its immediate predecessors.

No to Command-Oriented Design

Microsoft's Office 2007 group emphasised instead Results-Oriented Design:

• Think about features instead of commands
• Present functionality at a higher level
• Illustrate features by their results
• Use galleries to let the user close to the result they want to achieve as quickly as possible
• Visual! Tactile! Responsive!

No to Ribbonisation

You don't just "ribbonise" a form, any more than you "webify" an arbitrary desktop application. The most visible part of this UI design, the ribbon itself, must be supported by a host of other equally essential concepts and devices:

• Galleries e.g. for Visual Styles and Pictures
• Live Preview
• Contextual Tabs
• Quick Access Toolbar
• Mini Toolbar
• Enhanced Tooltips
• Enhanced Status Bar
• Live Zoom
• Customisable Status Bar
• KeyTips and Keyboard Navigation
• Streamlined Options
• Context Menus

No to the Task Pane

What's missing is as important as what's provided. With the ribbon scheme, Microsoft got rid of more than just the endlessly proliferating dockable multilevel menus and toolbars on every side of the display; also gone is the stack of task panes. Why? Added complexity, for one thing. Task panes don't actually replace anything, they just occupy more space, less productively, giving the user yet another place to search for functionality. Remember, one of the biggest ideas behind the ribbon is having a single point of access for that functionality.

Also: in Office 2003, everybody wanted to add a whole new task pane to the stack, for just their one feature.

No to Customisation

It can seem arrogant to lock down the UI, preventing users from arranging their toolbars, buttons and menus in their "favourite" configuration, or the one deemed most productivity-enhancing (who decides?) for their specific roles or requirements. In truth, more users hate their toolbar and menu docking freedoms. For example, two features of Office 2000 designed to simplify the UI by modifying it, namely adaptive menus and rafted toolbars, actually added so much complexity and disorientation to the user experience that most customers, especially those in corporate environments, turned both off.

As Jensen Harris puts it, 99% of all users' requirements were met by their eventual "static" ribbon design. But 1% of 200 million customers is still two million people; so, the status bar, and a single customisable toolbar, were left in for just those 1%. The point to note is that Microsoft in 2007 were in the happy position of having amassed so much customer feedback (over 3 billion data sessions collected from Office users; 2 million sessions and 40 million command bar clicks per day; 6000 individual data points; etc.), they didn't have to hypothesise about such things - they just looked at the data. You probably don't have that luxury. So, it's even more important that you allow your pet UI features to be questioned. Ruthlessly tortured, in fact. Probably killed.

No to Exceptions

Design tenets have to be religion. Microsoft's design tenet set in the summer of 2003 looked a bit like this:

• A person's focus should be on content, not on the UI. Help people work without interference.
• Reduce the number of choices presented at any given time.
• Increase efficiency.
• Embrace consistency, but not homogeneity.
• Give features a permanent home. Prefer consistent-location UI over "smart" UI.
• Straightforward is better than clever.

Religion: as in, consistently adhered to and applied.

The "Ribbon" User Interface

Update: someone suggested this article has appeared five years too late. Clearly not a Raymond Chen reader.

Caution!

We have added the Microsoft Office 2007 "Ribbon" style of User Interface (UI) to a number of our products in recent years. The results have ranged from the frankly perfunctory, in the case of our internal or consultants' tools, to the very professional, as with all of our high profile market offerings. In this process, we discovered a great number of troublesome issues, difficult decisions, points of contention, and design dilemmas. All of which, I hasten to add, are a good thing.

This is not a conversion that can be approached lightly, since - particularly by comparison with traditional menus and toolbars - the Ribbon UI:

• takes away so much of the user's freedom;
• eliminates "multiple ways" to execute actions;
• removes the comfortable familiarity a user has built up with your app over the years;
• occupies a bigger chunk of valuable screen real estate than the scheme it replaces.

For some people, myself included, just this short list of disadvantages has been enough reason to avoid ribbons, or at least try to, for years on end. If you are still in that category, then may I suggest that watching the following video. It might just win you over to what Microsoft tried to do in 2007. Yes it's as long as a football match, but it's absolutely fascinating, full of insights, sly ironies and unexpected twists. It's worth the price of admission just to play the archaeologist, to marvel at the long trail of rejected early prototypes. If you have any involvement at all in crafting the customer-facing surface of your app, then you owe it to yourself to let Jensen Harris walk you through the surprise-filled design process behind what was possibly the last ever WinForms, non-touch UI revolution of its size:

SCARB Does Security!

A Good End to the Day

Today I led SCARB, our internal Security Coding and Architecture Review Board, in a software security related meeting. As always seems to be the case, I found the agenda changing repeatedly up to and including half an hour before the start. Now that I think of it, in fact that agenda actually kept changing after the start of the meeting, too...

But that wasn't a bad thing! Thanks in part to the vagaries of the way these meetings are set up and run, we ended up with a larger than usual committee, and with representatives from across several different projects: Windows Forms, Web, and both; CQRS and relational; old and new. My presentation, detailing a good half dozen specific security related issues - and their mitigation - in one project, drew comments about the desirability of software and system security reviews in practice, and specifically mentioning the obvious advantages of starting such processes at the same time as the projects themselves.

People seem to particularly like concrete examples. Now, to obtain examples from your own code base, you have to have done a partial security review already. Which was in fact the case for us, at least with two of the projects concerned. Both had previously been taken into the stages of developing a data flow diagram of the system, and of identifying processes, data stores, data flows and the trust boundaries where the vulnerability categories must be investigated.

Now I know what I need to get buy-in, and push the review process further. More examples! SQL injection attacks that work and are demonstrable. XSS attacks, likewise. These can be taken from many resources available around the Internet, but I guess the closer to your own app in terms of applicability, the better. They'll also provide an excellent way of opening the mind to the plethora of attack vectors available to the attacker, encouraging the inclusive, brainstorming, "yes - and..." approach vital to the success of the review process.

And next time, we will have a game of cards.