Commitment Needs a Reason

Modern version control systems automatically record useful information every time we make a commit:

What?

The difference (diff) of every file is automatically recorded, so we can see the additions and deletions in each commit.

Where?

Every commit tracks the location (files) of each change, so we know where the bodies are buried.

When?

Every commit is timestamped, so it’s easy to find things that were changed yesterday, last week or ten years ago.

Who?

Every commit is associated with a person, so we know who to ask about that confusing conditional.

Why?

The reason for making this change is the only thing a version control system can’t infer, so it’s the only piece of information that should ever go into a commit message.

Version control systems automatically record the ‘who’, ‘when’, ‘where’ and ‘what’ of every commit. Please, use the commit message to tell us why this change was made.

(Thanks to Antony and Andy for helping me understand these ideas and write useful commit messages.)

 
 

Be Gentle With Enthusiasm

This discussion of empiricism, complexity and being gentle with enthusiasm, by yours truly, is clearly in gross violation of the spirit of a ‘pro tip’ but may be of interest to programmers or those working on Ruby on Rails projects.

Warning: contains code and high-horsedness.

Going Native

Are native apps faster than web applications? Do they feel better than web applications? Maybe.

As a user, there’s a bigger problem with web applications. They can be changed at any time, without notice.

The ability to change your product quickly and often is also a huge boon to creators of web applications. The godfather of startups, Paul Graham, in his seminal startup bible ‘Hackers and Painters’, calls this out as a huge advantage to startups: Release early, release often. Iterate!

The new ‘Lean’ literature is also full of this kind of thinking: Make a hypothesis about a change to your system, quickly build a barely-sufficient (sorry, ‘minimum viable’) version of a feature, deploy it to your users, then measure their response to test your hypothesis had the desired effect.

Now, rinse and repeat until you’ve attracted enough users to be aquihired by Google. Now you can become a V.C.

Circle of life.

Once in a while, this process of rabidly churning out changes to a product results in a beneficial long-term invention for users. It’s a hap-hazard approach akin to throwing shit against a wall and hoping that a masterpiece eventually reveals itself: If it eventually happens you look like a genius, but in the mean-time we’re all covered in shit.

I’m sick of having to re-learn the interface for your half-assed web app. I’m sick of your tweaking and polishing and rearranging and pivoting. It may be the most cost effective way for you to “innovate”, but you pass some of that cost to me, your theoretical, quote-unquote non-customer. Now I have to spend my time and and attention learning how to attach an email again, or figuring out why the workflow that I depend on is suddenly, maddeningly ever-so slightly different than it was five minutes ago.

There’s a reasonable argument that web apps feel less snappy than native apps, and sure that’s important to me. But it’s far less important than the feeling of relying on your web app for something and, in exchange, exposing myself to your shit-slinging innovation process.

I’m sick of being your lab rat, running desperately through the new maze you’ve dreamed up, frantically searching for that piece of cheese that I know you’ve hidden around here somewhere.

Why are web apps worse than native apps? Because they encourage you, big-shot startup entrepreneur, to experiment on me instead of thinking through the job that I’ve hired your software to do. And you’re not entirely to blame. I should be more discerning with my time and attention. I should be paying for a well considered, thoughtfully designed service that solves a genuine problem. I should be more circumspect about the use of my time and attention.

And so, it is with regret, that I must decline to sign-up for your shiny new web app. I will pass on your revolutionary new gadget. I really don’t need another way to watch my extremely limited time on this earth slip through your sweaty fingers in the name of “innovation”.

Good luck with your acquisition.

Not On My Wrist

MG Siegler gets excited about the prospect of digital, Internet-connected smart wristwatch personal assistants:

I want a Dick Tracy watch that can do all kinds of things beyond just making calls. Call/SMS notifications are a great first step.

Lining up watches as the next disruptive technology—much like the iPhone spawning the smartphone revolution—is tempting, but there are a few notable differences.

The big difference between pre-2007 cell phones and today’s wrist watches is that there are already wristwatches I want to use today.

My wristwatch is a result of the cumulative experience of an industry with hundreds of years of technology-advancement and craftsmanship under its belt, culminating in a seemingly living, breathing mechanical work of art that I get to wear on my wrist everyday.

My watch has precisely three functions: it shows the current time, the current day of the month and it has a mechanical alarm (seriously, mechanical). Its user-facing functionally is incredibly simple.

I love this watch.

In 2007, before the iPhone was announced, I owned a little Samsung slide phone. I don’t recall the model number. It was ugly, awkward to use and I hated almost every interaction with it. Before the Samsung I had owned some iconic Nokia phones, including the 5110, 7110 and 6110. All the Nokia phones I owned were good at their job: Functional cell phones. I loved none of them, but they were adequate. The iPhone changed that. It was the first cellular device that I felt genuine affection for. It was a beautiful, tactile little Internet-connected computer.

I loved that phone.

The iPhone was, at least, 100 times better than any other personal communication device I had ever owned. Moreover the iPhone was beautifully designed. It was an object of art. I felt the same kind of affection for the iPhone as I do for my watch.

Before the iPhone, cell phones were either terrible or adequate. Wristwatches don’t have that problem.

The wristwatch as a category for disruption seems like a much tougher proposition than cell phones. The watchmaking industry has a long, distinguished history of creating beautiful, functional items. Making a watch that’s 100 times better than the best in the market today will be an incredibly tough challenge.

But maybe I’m looking at this from the wrong angle. Am I acting like the people who continue to buy Blackberry phones because they absolutely must have a physical keyboard? Will the benefits of a tiny, wearable always-connected computer assistant trump the nostalgic beauty of a mechanical Swiss watch? For most people, I bet they will.

The market for watches with complicated, automatic movements will become even smaller and more niche, like vinyl record players, relegated to the realms of the enthusiast. In some ways I suppose this has been happening to high-quality watches since the advent of Quartz movements. Technology moves the purists along, if grudgingly.

I think I see where MG is coming from. He’s thinking about the customer experience first and working backwards to the technology. I do see the benefit of more portable, powerful, wearable, connected computing power. But not on my wrist.

The One Page Résumé

From time to time somebody will convince you to produce a résumé. This is a problem because résumés are awful.

Your résumé is too long, and too generalised. Make it shorter and more specific: A maximum of one single-sided printed page (A4 or U.S. Letter size), tailored to the hiring company.

Why one page?

A résumé should be designed to sell the concept of you working with the hiring company. Design is about compromise: Include only what’s essential.

To compromise you need a constraint. The one page résumé is your constraint.

When you have only one page you must think about more than just words. Think about the font faces, size and colour of those words. Think about the layout of those words on the page. Think about the negative space around those words. Think about design.

One page of words shows respect for the reader’s time and attention. They’re busy. They need help with something. Tell them how you can help each other. And nothing else.

Why tailored?

Hiring is a lot of work. Tailoring your résumé is more effort for you but it makes the hiring process feel more balanced.

Tell them why you should work together: How will you help improve their business? How will they help you improve yourself?

To answer these questions honestly you have to research the hiring company. How do they work? Who do they do business with? How do they make money? What do they value?

Answer these questions, then explain why you’re a good fit. Your honesty, insight and interest will be noticed and appreciated.

And finally…

Be bold and honest.

If, as you design your one page résumé, you don’t feel good about working with the hiring company then don’t apply. You will have learnt something about yourself and saved everybody some time and anxiety.

Try it: Think of your dream job. Now create a one page résumé that gets your foot in the door.

Tweetbot, Twitter and the Sunk Cost Fallacy

Tweetbot for Mac was released in the Mac App Store today. It’s priced at $19.99.

From the announcement on the Tapbots blog:

If you think about it, it’s not that expensive. Twenty dollars for a quality piece of software that you use every day? That has been the price point for quality utility apps on the Mac for years.

No arguments there. Tweetbot for Mac is a solid app that compliments my use of Tweetbot on iOS. I bought it because having a unified Twitter experience across my devices is worth the price.

But, honestly, the explanation of the pricing makes me nervous about the longevity of the app:

Once we use up the tokens granted to us by Twitter, we will no longer be able to sell the app to new users. […] We spent a year developing this app and it’s the only way for us to be able to make our money back and continue supporting it with updates in the future.

After the success of Tweetbot for iOS, building a Mac version must have been a no-brainer for Tapbots. But Twitter changed the rules half-way through development, putting a ceiling on the potential growth of Tweetbot for Mac. Now Tapbots need to recoup their development costs and find a way to support the app for the foreseeable future.

I don’t see how it necessarily follows that charging a higher one-off price gives Tapbots the ability to support Tweetbot for Mac long-term. Making a living selling apps on the Mac App Store is already difficult enough. As a customer, I’m nervous that Tapbots will lose interest once the Twitter tokens run out and the money dries up.

Tapbots have sunk a year of their time into building a product that depends on Twitter. Whether they manage to recoup that cost is one thing. The more interesting question is whether we, as Twitter users and Tapbots customers, should continue to sink more of our money and time into such a volatile platform.

Review of Photoset

Photoset is an iOS app from the makers of Tumblr that lets you combine a number of photographs into a grid-based layout and share them on the web via a secret URL.

As an app, Photoset is reasonably well designed without being breathtakingly beautiful. The UI is simple and understated.

Photos can either be selected from the Camera Roll or taken from within the app. As photos are selected, Photoset arranges them on a grid. Tapping and holding a photo allows it to be dragged and repositioned elsewhere on the canvas. Photoset does a reasonably good job of shuffling the other photos around on the canvas as you move a photo, to allow for different layouts. The effect is similar to the way iPhoto for iOS allows dragging photos to create album layouts.

Caption, location and date meta-data can be added to a Photoset, which appears on the web-based version.

When you’re happy with the look of your Photoset, it can be uploaded to photoset.com. Optionally the Photoset can be uploaded to a Tumblr site.

Once uploaded to photoset.com a custom, random looking photoset.com URL allows your photoset to be viewed in a web page designed and laid out to resemble the app. Clicking on a photo in a browser shows a larger version of the image in a carousel-like layout.

Photoset URLs can also be shared via Twitter and email, from within the app.

A history of all your previous Photosets can be viewed in the app. From here, Photosets can be shared and their URLs retrieved. Photosets can also be deleted from this screen, and new Photosets created.

Over the past week I created a number of Photosets to test out the app. I found it particularly useful to post a collection of images that I had taken on my phone but not shared anywhere else. For example, when my Elevation Docks finally arrived last week, I added photos of them to a Photoset and shared them all at once, rather than jamming up my Twitter timeline with a dozen individual photos of very similar things.

My concern for Photoset is that it does not have the stickiness of Instagram. I don’t feel compelled to share often because I need to have taken at least three photos—although Photoset does not impose this restriction—to make it feel worthwhile.

Because there’s no following/follower social network built into the service and no image filters to add mood and personality, there just aren’t enough reasons to launch the app frequently.

Instagram is addictive because it encourages you to create or consume depending on your mood and available free time. Photoset, in contrast, feels less about creating something artful, and more about simply sharing a batch of photos: Occasionally useful, but not much fun.

The App Store's Search Interface Trade-off

The App Store received a significant user interface redesign in iOS 6. The Lightwood Games blog shares “everything that’s wrong” with the update, including the new search result listings:

Now, instead of the native app table view, we’re presented with just one app per screen. A full thumb swipe from right to left is required to move to the next item. You can’t just zing your finger to the left and cause a bunch of apps to whizz past either. There’s no physics here. One gesture moves precisely one page.

While I don’t agree with everything in the Lightwood piece, the change to search results from a vertical tabular list, to a horizontal carousel-list is worth comment, as I believe it is a trade-off between “browsing without really knowing what I’m looking for”, and “searching for something specific”. Apple appears to have shifted the emphasis to the former, at the expense of the latter.

The goal of a list in most interfaces is to present a number of options from which the user has to pick a single item (multi-select list boxes excepted).

There are two interesting properties of list interfaces that effect their utility, depending on the goal the user is trying to achieve:

Scroll Direction

Horizontal or vertical? When it comes to selecting a single thing, usability testing shows that vertical scrolling is preferable. Jakob Nielsen:

We know from user testing that users hate horizontal scrolling and always comment negatively when they encounter it. Customer satisfaction is surely reason enough to avoid horizontal scrolling.

Whatever the reason, vertical scrolling was the more familiar and intuitive paradigm among users of the web, circa 2005. However, since this piece of web-usability research was done, Apple have used horizontal scrolling with some success in native interfaces. Remember Cover Flow?

First popularised by iTunes in 2006, Cover Flow demonstrated that a carousel-like horizontal list was a desirable method for browsing graphical representations of items. Cover Flow does a great job of showing off one item in a list, one at a time: Album covers look beautiful in iTunes.

In 2007 Cover Flow made its way into the OS X Finder for browsing documents and photos inside a folder. The iPhone and iPod Touch have since adopted the Cover Flow interface for browsing music.

The horizontally scrolling carousel-list interface, is really good for idly browsing through a list when you’re not sure exactly what you’re looking for. But when the goal is to choose one specific thing, flipping through a collection that is not sorted for relevance, one item at a time, feels ineffective and wasteful.

And that’s the problem with the new search results on the App Store: If I’m trying to select just one app from a list, and that app isn’t the first one, then I have to go through an inefficient horizontal swipe until the one I want is selected.

Worse, because the horizontal list doesn’t feature the helpful Cover Flow physics to help scroll quickly, after a few swipes I’m ready to give up.

Sort Order

Sorting a list helps us locate items relative to each other. We understand that the entries in our Contacts app are sorted alphabetically, so we know that ‘Jane Smith’ will be further down the list than ‘Johnny Appleseed’.

Sorting search results is a radically different challenge to sorting contacts because now we’re talking about sorting by relevance. Just look at how much engineering effort Google spends making the first result in their web search the most relevant to your query.

When you get really good at sorting by relevance, subsequent items in your list of results become irrelevant. When was the last time you clicked onto the second page of a list of search results? This is the reason Google’s ”I’m feeling lucky” button exists: Google got so good at sorting their search results by relevance that they can send you directly to the most relevant result for your search terms.

If the App Store’s search results were sorted by relevance such that the first or second items in the list were always the thing we wanted then the new interface makes perfect sense. If I always found the app I searched for in the top five search results, I could probably forgive the sluggish scrolling.

But in reality the App Store search results generally leave a lot to be desired.

Here’s an example: Last night I wanted to install the ‘Oxford Dictionary and Thesaurus’ app, so I entered the search term ‘Oxford Dictionary’. There are a number of Oxford branded reference apps for sale in the App Store, but the first one—which happened to be the official ‘Oxford Dictionary & Thesaurus’ app that I was looking for—appeared at number 88 of 7,622 apps.

To reach the 88th app in the new App Store took minutes of scrolling, because I had to look at each app to see if it was the one I wanted.

The Trade-off

Apple is not a search company. I’m sure they will continue to improve the quality of their search results, but having super-accurate app search results has not prevented people from purchasing billions of apps. In order to sell a lot of apps, the App Store needs to be optimised for browsing, which makes the horizontal list interface a much better choice.

There’s also now a uniformity to the App Store tabs. Along with search results, the ‘Featured’, ‘Charts’ and ‘Genius’ tabs use horizontally scrolling lists to promote more browsing.

It’s easy for the average person to open the App Store, enter a vague search term and then browse through the horizontal list. And if you find more than one app that takes your fancy, that’s great because the iOS 6 App Store allows you to buy and install multiple apps from any list without leaving the store.

While search may be a little frustrating if you know exactly what you’re looking for, Apple is now training you to buy a few things you didn’t know you needed, on your way to finding the thing you actually wanted.

They're Not Customers, Mark

Mark Zuckerberg talks to Bloomberg Businessweek about Facebook breaking one billion active users:

[…] I was talking to [Facebook board member] Marc Andreessen about this and he said the only two companies that he thought of that had a billion customers are Coca-Cola and McDonald’s.

Brilliant trolling? Blissful ignorance? Honest opinion?

Given the direction of the share price, I’d say Facebook is a long way from one billion customers.

Clock-Watch During FaceTime Calls

It always bugged me that it was impossible to see the time during a FaceTime call.

In iOS 6, a single tap anywhere on screen during a FaceTime call brings up the status bar, complete with the clock and battery status.

This is exactly the behaviour I always expected during a FaceTime call, so I was delighted when it actually happened today.

Update: I was asked to provide a screenshot of this feature in action.

Three UK Offering PAYG Nano SIMs in Store

Yesterday I wrote that O2 were the only UK carrier offering pre-paid nano SIM cards and specific plans for the iPhone 5 launch, however, Three is offering all their pay as you go plans, on nano SIMs, in stores today.

The Three website doesn’t mention the availability of the nano SIMs. I spoke to a Three online chat operator on Thursday, who told me there were no plans to offer pre-paid nano SIMs and that I should “keep an eye on the website”. But I can confirm that nano SIMs are available, having been to the Basingstoke Three store this morning.

The benefit of choosing Three over O2 is the data: Three’s best plan is the “All-in-One 15 Add-on”, which has unlimited data, 300 minutes and 3,000 texts, for £15. Compare that to O2’s best data offering of 250MB, 250 minutes and 2,500 texts for £20, and it seems like a no-brainer.

GiffGaff Stall on iPhone 5 Nano SIM

UK virtual mobile network operator GiffGaff announced its plan to support the iPhone 5 on its contract-free SIM only plans:

If all goes well, we hope to have the SIM cards ready for distribution in the coming months.

The vocal GiffGaff community expressed their dissatisfaction, resulting in an several vague, apologetic updates, culminating in this:

The process for delivering the nano SIM on giffgaff was kicked off several weeks ago and is being treated as a high priority, but there are some steps which simply cannot be made faster. For these reasons, at this stage, the company cannot commit to detailed delivery timescales, but we are expecting to launch nano SIMs before the end of this year.

GiffGaff are a wholly owned subsidiary of Telefonica/O2 and rely on the telecommunications giant to provide all of its infrastructure.

GiffGaff behaves in some ways like a “small, lean company”, but they are firmly tethered to the mothership. While it looks like a disruptive upstart in a staid industry, GiffGaff is actually a mechanism for Telefonica/O2 to test out risky ideas on a flexible, responsive segment of the market.

The only reason for GiffGaff not to offer nano SIMs on iPhone 5 launch day is because they have not had the nod from their corporate overlords.

Why would Telefonica/O2 delay offering contract free iPhone 5 plans on GiffGaff? It may be because O2 are the only UK carrier offering prepaid (contract free) nano SIMs on launch day.

That’s a huge differentiator for O2. Given that they don’t have an LTE offering, and won’t have one for the foreseeable future, I suspect they want to hold onto as much of the iPhone 5 market as possible. If that slice of the market has to come from prepaid customers, then O2 will take it.

GiffGaff will get nano SIMs eventually, but only after O2 grab the early prepaid adopters.

Much Better

When a product you use every day suddenly changes radically the effect can be jarring.

When Apple changed the look of the iPhone 3G, it was jarring. So too, was was the redesign of iPhone 4. Those generational redesigns were significant aesthetic changes, that made people stop and take notice.

But the aesthetic of the iPhone 5 is very similar to the iPhone 4. So similar, that some may feel underwhelmed by the update. And that’s before you even consider the glaring omission of NFC, that useful, ubiquitous, life changing technology (I jest, others don’t).

When Apple announced the iPhone 4, I only bought one after seeing it for myself. The design looked very different, and it was the Retina screen that convinced me to part with my 3G.

This time it’s different. I don’t need to wait for the reviews because it looks beautiful. I’m not jarred by the new aesthetic. It’s not a shock to the system. The differences look subtle and natural. A much loved, well used device, better in almost every way.

The biggest change this time around is a slightly taller screen. But why, after five years, have Apple changed such a successful formula? Phil Schiller explained during the keynote:

Same width, but taller.

But why? What is the design centre for a phone? It’s this: Your hand.

When you carry your phone it should fit easily in your hand. It should be easy to send messages, type email and surf the web. And that’s just how we designed iPhone 5.

As iSpin explained earlier this week, iPhone’s width is perfectly suited to the average width of the human hand. The screen height was the only variable that Apple had leeway to change. Apple’s premise is that a taller - but not too much taller - screen gives a much better experience.

But if you want to understand why the iPhone 5 looks so similar to the iPhone 4, look no further than the screen: It is the device. It’s so important that Apple - one of the most calculating, meticulous, design-focused companies in the world - hasn’t changed its size for five years.

This screen resize represents the single, most dramatic aesthetic alteration to the iPhone since the original shipped in 2007. Apple’s designers don’t do things by accident. This is a huge deal.

It’s such a big deal that Apple had Jony Ive discuss the reason for the muted aesthetic changes:

When you think about your iPhone, it’s probably the product that you use most in your life. It’s the product that you have with you all the time. With this unique relationship people have with their iPhone, we take changing it really seriously. We don’t just want to make a new phone. We want to make a much better phone.

The changes in aesthetic between all previous iPhone generations were made for specific reasons. This year, the brief was clear: Thinner, lighter, “more room to work and play” (Schiller).

The iPhone is not a design playground. It’s too important to the people who use it everyday, and therefore too important to Apple’s business. Great design should make things look new, but only in the service of making great products much better.

A Pretty Maniacal Group of People

Farhad Manjoo pieces together some iPhone pre-history, using evidence submitted during the recent Apple Vs. Samsung trial. The effort and institutionalised secrecy involved in its production seems staggering.

Apple has an extensive array of systems to quickly create physical prototypes of digital designs, and the team would handle all of these prototypes and remark on how they felt. “We’re a pretty maniacal group of people,” [veteran hardware designer Christopher] Stringer explained, pointing out that they would sometimes review 50 different refinements of a single hardware button.

Yes, the patent system is broken. Yes, big corporations are litigious. The Apple Vs. Samsung verdict doesn’t change anything. It makes the patent system no more or less legitimate. It makes the act of suing your competitors no more or less morally objectionable.

But then you hear how a successful, disruptive product was willed into existence through years of hard work and secrecy. Then you see hundreds of prototypes that were painstakingly designed, tested and discarded. Then you get a sense for the tiny, “obvious”, details that were included because someone really used the device, every day during its creation.

Then, knowing all this, how can you begrudge the creators the opportunity to prove that their work was shamelessly copied?

This trial was not about the patents. The patents were just another piece of evidence that Apple used to support the story, that they poured years of hard work into the iPhone, which Samsung simply copied and reaped the rewards.

Instapaper Blocked 9to5Mac

As I speculated yesterday, 9to5Mac were not blocking the Instapaper bookmarklet. The site had been added to Instapaper’s publisher opt-out policy.

Marco Arment explains why it was him, and not 9to5mac, who instigated the opt-out:

The best way to prevent Instapaper from accessing 9to5Mac’s pages was to add them to the opt-out list. So I did that, thinking I’d let the dust settle and reevaluate that decision later once I had a better idea of how they felt about Instapaper.

As Marco admits, he overreacted, made a hasty decision, caused confusion and inconvenience for some of his users and probably didn’t do his reputation much good. But an explanation and an honest apology seems like a good recovery, to me.

9to5mac Blocking Instapaper?

Harry Marks:

Now, why anyone from 9to5Mac would think anything from their site would be worth saving to read later, let alone at all, I don’t know. They apparently don’t read anything they write.

I’m not sure if 9to5mac.com is blocking the Instapaper bookmarklet. They could have simply opted out from Instapaper text parsing:

Most publishers value the increased engagement, retention, and social interaction that Instapaper encourages among their readership. But any publisher can choose to opt out of Instapaper text-parsing compatibility.

Whether you should choose to read 9to5mac, or its ilk, is another issue.

Neven Mrgan's Portland Food Guide

Neven Mrgan:

Have fun, and remember: there’s no reason to ever have a bad meal in Portland!

I’m writing this in Portland airport, on my way back to London after a two week work trip. 

During my trip I solicited and sampled some of Neven’s food recommendations. Now you can see them all on one convenient page. 

My favourite dinner spots were Wafu and Pok Pok; both on SE Division. For brunch, The Woodsman Tavern was excellent.

I also spent a lot of time in the Stumptown Coffee cafés dotted around the city. Get a Chemex of the Gatomboya, if you like to start the day with a beautiful, fussy coffee

Dash Docset for Rails 2.3

A Dash docset for Ruby on Rails 2.3, by Juan Ignacio Pumarino.

Unfortunately the repository’s feed didn’t work for me, which means I won’t get automatic updates.

To install manually, download the tar.gz or zip version of the source code, extract them and point Dash’s New Docset preferences dialog at the extracted source.

I assigned the Dash search prefix to :rails2, so I can search the Rails 2 and 3 documentation independently.

It would be helpful if Dash showed the name of the Docset against a search results, to help differentiate between versions.

App.net Perspective

Harry Marks brings some much needed perspective to the recent spate of hypocritical ‘App.net is a country club for rich white people’ sensationalising:

Just a reminder: App.net is about making a better, more open Twitter competitor that doesn’t rely on ads to generate revenue. It was NOT designed as a way to keep poor people and minorities from using social networking tools. And if you do see App.net as a shift toward a “race war” or a “class war” on the Internet, please turn off your computer, call your ISP, and disconnect your service. Your privileges have been revoked.

Fixies and Growthers

Aaron Swartz:

 Fixed-mindset people feel smart when they don’t make mistakes, growth-mindset people feel smart when they struggle with something for a long time and then finally figure it out. Fixies try to blame the world when things go bad, growthers look to see what they can change about themselves. Fixies are afraid to try hard — because if they fail, it means they’re a failure. Growthers are afraid of not trying.

A joy to read.

(Via Kontra)

The City A Prehistoric Survivor

Nicholas Shaxson for The New Statesman:

The [City of London] corporation is an ancient, semi-alien entity lodged inside the British nation state; a “prehistoric monster which had mysteriously survived into the modern world”, as a 19th-century would-be City reformer put it. The words remain apt today.

Fascinating article highlighting the ancient, mysterious power of the City.

Shaxson’s book, Treasure Islands, is worth reading.

Diversity Sucks

As 10,000 early adopters pledge $50 each for early access to App.net, The Kernel’s Mic Wright, bemoans the ‘reverse gentrification’ of social networks:

But as Facebook and Twitter enter the mainstream, elites have begun to grumble that newcomers don’t know how to “do it right”, as if the cultural rules imposed by them in the early days are immutable.

[…]

For all its philosophical posturing about Twitter being a big meanie and the nature of openness, what App.net is really about is that geeks are getting uncomfortable with normal people encroaching on their space. That $50 fee is the equivalent of a massive stone wall around a gated community.

This wilfully misses the point of Twitter, which appeals to diverse groups because they can coexist without ever acknowledging each other.

If Twitter becomes popular among people who’s updates don’t interest me, then I choose not to follow them.

Twitter encourages individuals to create their own personal communities, which are gated by the explicit follow mechanism.

Wright continues:

Underlying App.net’s manifesto, there is a simple sentiment: diversity sucks. What’s really tweaking the nipples of the snarky tech classes is that people who shop in stores that aren’t “cool”, don’t know a damn thing about Ruby and can’t afford a new MacBook Air every year are suddenly having fun on “their” social networks. Intolerable!

Personally, I backed App.net because I value diversity. But diversity comes in many forms, and I’m specifically interested in the diversification of Internet business models.

Why should the only viable online business be selling user’s eyeballs to advertisers? I’m more comfortable investing my time, attention, and yes money, in a customer-vendor relationship.

Wright’s sensationalising, tabloidesque perspective of the motivation behind App.net’s backers, also fails to acknowledge a larger idea: Alpha is just a reference implementation on top of the App.net infrastructure to help orient new users, which is why it looks like Twitter. Eventually Alpha should be free for everyone to use, and some of it may be supported by ads. But the real potential of App.net is as infrastructure for social web applications.

As Orian Marx points out:

Social web apps are built around concepts like users, posts, connecting and sharing. App.net will provide a scalable infrastructure and a base model for these concepts upon which startups can innovate without reinventing the same wheels again and again. Developers will spend less time just trying to make their applications functional, so they can have more time to make them unique and useful.

Metaphor and Mitosis

On a recent project we used metaphors to help convey information about the system we were building, among our relatively small team.

The software was a run of the mill E-Commerce affair, featuring examples of customers purchasing products. There were rules effecting the sale of products, depending on certain properties of the customer, among other things.

After initial discussion with the designers, business people and information architects, we settled on the metaphor of customers taking a journey, guided through an online store, down a number of paths to purchase items. The items available for purchase along the journey depended on the customer, and their relationship with the business. Eventually, all journeys concluded at checkout, where external fulfilment systems provision the customer with their goods and services.

Initially, we started with a small team, working on a code base containing the usual suspects for building an online shop: An MVC application and a database.

After a few sprints the team was split into two, due to a desire to reuse the persistence part of the application across other business software. The metaphor (not fully explored) for the persistence layer emerged as a product catalogue; the canonical source of information for products sold by the business.

While we explored the guided journey metaphor, we neglected the product catalogue and allowed our understanding of layered software architecture to drive many design decisions: By thinking in terms of a service oriented architecture, we ended up building a horizontal slice (the database and REST API), and a single dumb client (the web application), that basically rendered JSON responses from the catalogue. The business logic for guiding a customer on their purchasing journey lived only in the horizontal product catalogue layer.

The metaphor was strained and unclear at this point and tension was building as we struggled to ignore the elephant in the room: the second client of the product catalogue service.

A third team started work on the second client of the product catalogue: An agent facing version of the online shop, designed to allow a sales representative to assist a customer with their shopping over the phone, in real-time. We quickly learnt that sales agents can deviate from the guided journey that the customer would be required to follow. In fact, the sales agents could bend our carefully constructed rules so much, that the API and business logic of the product catalogue was almost totally unsuitable for the agent-facing shop team to work with.

The product catalogue team attempted to meet the demands of these wildly different clients by declaring bankruptcy on their existing API and pushing more of the business logic out to the consumers. They reduced their responsibilities and went back to being a much simpler persistence layer, with a more generic search and purchase API.

All of the business logic for the guided journey now needed a new home. Some of it moved back into the client facing shop. Some of it moved to the agent facing shop. The common pieces of logic started moving towards a third system, to be shared by the two clients. For practical purposes, the two teams shared the code and started moving it into its own code base.

Throughout the project we felt the frustration of a metaphor that just didn’t seem to work. We spent a lot of time talking through the metaphor of the guided journey, without ever really reaping the benefit we felt it deserved. The reason for this, only became clear to me after recent conversations with Antony and Andy.

Instead of trying to stretch the edges of the guided journey metaphor past the point of usefulness, we should have embraced that pain and realised that a system can be usefully described by multiple metaphors. Had we recognised the product catalogue and the guided journey were overlapping but separate metaphors, we may have foreseen the problems caused by the next client of the product catalogue.

The agent facing shop, I have since recognised, could have used any number of interesting metaphors that ran parallel to the others. For example, what if the agents were super heroes, who were not bound by the same restrictions that mere mortal customers were? What if the world the super heroes and the regular people shared had emerged as a set of basic physical laws (a force like gravity; or a force like having to exchange money for products and services)?

If we had recognised the points where our metaphor was strained, and explored new metaphors as separate but overlapping things, perhaps we would have split our teams and systems differently; separating concerns and building a more flexible, emergent architecture.

Before this project, I appreciated that a metaphor can be a powerful carrier of information between small groups of people. I now believe that if we recognise a metaphor breaking down as a signal to split the system; a sort of ‘system mitosis’, splitting our existing architecture into naturally occurring interdependent systems. Together these systems, and their metaphors, convey a holistic story, and history, of their world in their own words.

Andy Palmer on Patterns, Idioms and Metaphors

Andy Palmer used this description of Patterns, Idioms and Metaphors recently to help explain them to a client, which I paraphrase here for posterity:

Patterns carry a medium amount of information to a lot of people and cross language boundaries.

Idioms carry a small amount of information to a medium amount of people; for example, “this is how we do loops in Ruby”.

Metaphors carry a huge amount of information to a very small amount of people. A metaphor is something that works at the company level or smaller. It carries a lot of information and gives people within an organisation a common language.

We find that if we boil a problem down to its essence by producing an appropriate metaphor, then that knowledge tends to spread among a small group faster, while retaining more useful meaning, than via other mediums.

What if Apple Buys DuckDuckGo

Benjamin Brooks fantasising over Apple replacing Google search with a combination of DuckDuckGo and Wolfram Alpha across the board:

not only would this be a blow [to] Google, but to Microsoft as well. This would give people a true reason to use iOS and the Mac, it would keep money out of competitors hands, and would be a game changer.

One big problem with DDG is its localised search results, which are basically non-existent compared to Google. 

If Apple added a third company to its list of acquisitions, one that had excellent localised search results, then this theory starts to sound plausible. Perhaps buying localised results from Bing, in the interim, would work.

Transcript of Build and Analyze 89

Dan: Can anyone in the chat room confirm that; how are our levels? Are we loud enough?

Marco: Are we level?

Dan: Are we level? Are we on the level?

Marco: Are we level enough for you?

Dan: Marco, are you on the level?

I needed a couple of quotes from this 5by5 podcast for a recent note, so I transcribed the whole episode.

People Running Companies

One of the greatest quotes from this 1984 unused Apple commercial is from Macintosh marketing manager Mike Murray:

And I think what you’re going to see, is that the balance of power is going to shift; the balance of power from companies running people to, hopefully, people running companies.

Murray never even mentions the product, but this quote speaks volumes for what must have been motivating people at Apple early on.

Instapaper is not a Platform

I’ve been sporadically working on a project called papyr, for RiverGlide, since April. It was intended to scratch an itch that we had around making good reading material available at convenient times. You can read about the background, if you’re interested.

One of papyr’s two major dependencies is my favourite ‘read later’ service, Instapaper. We knew we wanted to make content available offline in a beautiful reading environment, and we were already Instapaper users. It seemed a natural fit.

Conceptually, papyr is very simple: it watches your Twitter timeline, looking for readable articles, rather than movies or images, for example, and saves them to a folder in your Instapaper account.

Two weeks ago we started allowing the first beta testers onto papyr. We quickly ran into problems, as our intended use of the API is technically against the Instapaper terms of use. Instapaper creator Marco Arment, explained his position in an email to me and made an exception for papyr, under the condition that we kept the volume per user to a reasonable amount per day, which we have done.

This whole experience has made me question our implementation of papyr. It partly solves the problem we had, but right now it’s at the expense of a service I value.

There was a timely discussion on this week’s episode of Marco’s podcast, Build and Analyze. During the show Marco answers a question relating to rate limiting, posed by a listener and Instapaper customer, who has also fallen foul of the new rate limits:

I did, about two weeks ago, as [Michael Festler] noted, add a rate limit to ‘adding things to read later’. And there were a few reasons for this. One of the biggest ones was that there’s a number of services cropping up out there, even though I forbid them in the API documentation, services that will basically pipe RSS feeds into your Instapaper account automatically. And what this results in, much more often than not, is people having thousands and thousands of unread items building up fairly quickly. And that pretty much ruins an Instapaper account for any real use.

That’s right: One of the offending services is papyr.

Marco goes on to explain:

And I don’t mean for everybody to read everything they save, I don’t even read everything I save; not even close, but, when you can very quickly build up ten thousand unread items, not only is the service not really meant for that and it’s very expensive for me to keep hosting, but it’s just bad for you, the user.

Preventing that kind of build up, is important for the service to do, just to keep users from shooting themselves in the foot too bad. The service is not designed for that, it won’t work well with that. The app certainly won’t work well with that and it’s just a waste. It’s a waste for everybody.

I’ve experienced problems with the app on iPhone and iPad caused by these volumes. When the turnover of articles is high the app downloads hundreds of articles to the device whenever you launch it, which is twice per day when commuting.

Usually there isn’t time to load everything before losing signal (on a train, for example), which results in not having anything new to read. And now, because the older things have been pushed out to make room for the new, there isn’t anything to read at all.

The Instapaper iPad app, I have found, is also fairly unstable when dealing with a large turnover in articles. If I scan through a folder of one hundred unread items; reading, deleting, archiving and sharing as I go, the app will generally become unstable and crash after ten minutes. I can imagine this being a side effect of dealing with so many articles.

Marco also shared the article limit for each user:

So, I want to set this limit, somewhere that normal reasonable use is never likely to hit. And I think 120 per day, is not that bad of a number to set, maybe I’ll have to raise that; I’m certainly going to evaluate that. But I don’t understand, honestly, how somebody can save 120 things per day and actually read any meaningful portion of those.

And he’s right. Even on my best days I can only manage to read about twenty articles during a normal commute. And when I’m not commuting, as I haven’t been for the last few weeks, the unread list simply builds up to an unmanageable level.

Today I paused papyr for my account, which all papyr users have the ability to do. I haven’t been keeping up with what’s been saved for me recently, so it makes sense to take a break, and it will reduce the load on Instapaper a little.

But aren’t all Internet services, that expose APIs, designed to be mashed up and used to create amazing new things? Perhaps. But we should consider the cost to the provider and our impact on the service.

Some Internet services have grown large and successful because developers and third parties built on top of their APIs and created value that the service owners had never dreamed of.

They became platforms.

The best two examples, Facebook and Twitter are not, however, great examples of successful, sustainable businesses. One is hugely overvalued and its share price is currently collapsing under the weight of expectations, and the other still hasn’t figured out how to monetise its service, but its attempts have driven the early adopters to look around for something better.

Marco has created a business that sustains him and his family, simply by making a useful service, charging money for it and not spending more than he makes. He has, as far as I know, rejected offers to take funding.

For papyr, I believe this means that Instapaper can’t be part of our solution.

We built papyr with the genuine intention of solving a problem and making things easier. It’s not fair on Marco or the Instapaper customers, some of whom we hoped would become our customers, to burden the service in a way that Marco has specifically identified as detrimental for everyone.

Marco seems to be saying that Instapaper is not a platform:

So when you’re saving 49,000 or 50,000 articles, what could you possibly be using my service for that it’s going to work well for?

That’s the big thing: What are you doing with all these things? And if the answer is, nothing you can possibly do with this can work well and can serve you well even, and I’m just taking on a big burden for hosting it all, what am I supposed to do?

If Instapaper is not a platform, then we’ll respect his decision and stop treating it as one.

Serendipity for Squares

Antony Marcano explains the benefits of embracing the serendipity economy within an organisation:

Ensure that employees have social networking tools at their disposal. Share the ideas. Create a simple sign up page that’s sent out to employees or even the general public. Get feedback. Provide “seed-funding” to the projects that inspire the most passionate responses. Get the first few features built. See how hard or easy it is. If it works out, you’ll have empirical data to base future estimates on and you’ll have the beginnings of the product (maybe something releasable).

For established organisations, with a solid brand image, adopting an experimental culture may seem risky. How would you feel if your bank or insurance company started exhibiting the behaviour of a lean startup? Shareholders and the stock market may react poorly to this kind of apparently wild business experimentation.  

But companies don’t have to drag their carefully cultivated brand through the uncertainty of the lean start-up mire in order to exploit the serendipity economy.

Using Antony’s MARTA heuristic, let’s try to think beyond risk mitigation: embrace serendipity and test our new ideas on the market, while protecting our established brand, and maintaining customer loyalty and shareholder confidence. 

Let’s assume for the purpose of this thought experiment that our company has a reasonable handle on internal privacy and controls media leaks. We start by introducing access to an internal social  media platform (like Yammer, or Glassboard). We actively encourage employees to participate in public social networks (Twitter, LinkedIn, Facebook et al.), while making it clear what information we do and don’t want sharing on these platforms. We provide time and space for employees to meet informally and encourage cross-pollination of teams, divisions and ideas. We introduce twenty-percent time and encourage people to self-organise around solving the problems that they care most passionately about.

When interesting new projects and product ideas start to emerge we help them flourish, while gathering feedback internally. When we’re ready to take the plunge and test an idea with the public, we can start thinking about managing the risk. 

We could opt to mitigate the risk of our customers and shareholders losing confidence in our brand by testing our ideas quietly. A subset of our most loyal, sympathetic customers are a good place to start; friends and family are a relatively safe audience.

If we decide that an idea is contrary to our brand, values or the market for our idea does not appear substantial enough, we could simply avoid exposing it to public scrutiny.

We could reduce the risk of damage to our brand by framing the idea as research or as being “just a hobby”, as Apple has done with the Apple TV since its introduction.

We could transfer the risk to someone else by hiring a specialist company to build and test our idea under a totally different brand.

And if we decide that the idea is close enough to our core business that the risk of damage to our brand is acceptable, we could simply push ahead and test it out in the open.

Being a big, trusted brand shouldn’t preclude us from acknowledging, embracing and exploiting serendipity. Failure to innovate, invent and adapt can be a killer; just ask Kodak and RIM.

Retinafication Flow Chart

Thomas Fuchs has created a handy flow chart (PDF) to guide you through the minefield of creating or modifying image assets for display on high resolution (retina) displays.

Fuchs is also writing a book on the subject.

Brooks' New Business Model

Benjamin Brooks on the new business model for The Brooks Review:

All non-members of the site will have access to every post that members have access too, with one caveat: non-members won’t see those posts until seven days after I posted them.

Gutsy move. I’m looking forward to updates about the impact of this change on Brooks’ ability to produce work that he’s proud of.

I was hoping TBR would adopt a ‘pay what you think it’s worth’ model, as I suspect it gives a deeper insight into the true value of your work. With Brooks setting the price himself ($4/month), and not disclosing how he arrived at that price, he may have missed the opportunity to discover what value his readers really place on his writing.

However, this is a line in the sand. Other writers can use Brooks’ business model, and pricing as a precedent for going user-supported, and as a benchmark for setting their own prices.

DHH on Levels of Aspiration

David Heinemeier Hansson, with an uncharacteristically non-inflamatory post:

To help someone move up the hierarchies, they have to have an intrinsic desire to do so. Arguments like “but it works” or “it gets the job done” are tell-tale signs of someone happy at the lowest level of the technical hierarchy and your cue to just quietly back out of the debate.

The diagram of the different aspirational levels is necessarily simplistic, but seems like a useful heuristic for having productive conversations about technology choices. Or at least for keeping them short.

Refactoring to the Y-Combinator

A wonderful video of Jim Weirich refactoring a Javascript factorial solver into the mythical Y-Combinator function. The introductory explanations before the refactoring are worth the price of admission alone.

Product Placement for Internet Writers

There’s been a brouhaha recently about (mostly independent) Internet writers (not) making money from their web sites.

On one side are the read later services like Instapaper and Readability that allow readers to take the content out of its original site, remove all the ads and other extraneous rubbish, and nicely format the text and layout of the page for an enhanced reading experience.

On the other side are the poor independent writers, who live and die by the page-view. What happens if no one clicks their ads because they have been removed by a read later service? Where does their revenue come from?

There are any number of novel business models that independent writers use to bolster their meagre incomes; like selling premium content to subscribers, selling T-shirts and other swag and placing ads into their RSS feed.

But I would like to specifically address the issue of the read-later services. If someone is taking your content, modifying it from its original form and removing the ads, then perhaps a more subtle advertising mechanism is in order.

Movies and TV have been doing this for a long time: It’s called product placement and, if well executed, it can be very effective. I’m far less likely to be offended by well chosen product placement in a movie, than an image (or, horror, Flash) advert on a website.

If your ad is presented in a format consistent with the bulk of your core offering, text, then it’s likely to be better received by your audience, and much less likely to be removed by read later services for distracting from your actual content.

If your site is primarily about images, like Flickr or Instagram, then users will be more sympathetic to, and engaged with, ads that are images. Ditto for movies, ditto for audio.

Writers: if your business model requires ad revenue that’s fine, but make your ads text-based and relevant to your audience.

Ad syndicate networks: make your ads available to writers in well written plain text format, with a single link.

As a reader, I favour the whole-post text ad (a la Daring Fireball’s two sponsored posts per week). But I could tolerate a clearly marked in-line text ad for something relevant to me and the content I’m reading about.

And no, I don’t believe Readability’s shady revenue-redirection business model, which they ditched recently, is an acceptable compromise for readers or writers.

Clumsy and Impractical

Adrian Kinglsey-Hughes’ “Final thoughts on Windows 8”:

 Bolting on a new user interface is one thing, but when that user interface is incomplete, it makes you question the value of having it in the first place.

One of Hughes’ predictions for Windows 8 seems unlikely:

Windows 9 will look significantly different to Windows 8, and likely switch back to the ‘traditional’ Windows interface;

As usual, Microsoft’s dependence on the Enterprise and the ponderous pace of change in corporate IT departments means it has to drag the baggage of the existing Windows brand and interface along for the ride. 

If Microsoft push ahead and release Windows 8 as-is then I think it has to stick with it, leaning on the OEM vendors to push it to consumers and pulling strings at the upper echelons of big corporates. 

Microsoft has been able to offer inordinately long-term support to big business customers for so long because of its unassailable market position in the PC era. The mobile and touch-based device market does not afford them the same luxury and they might just find the Windows baggage too heavy a burden to bare this time round.

I don’t see them backing away from Metro as a product, but I could see them splitting Windows 9 into more traditional desktop and mobile flavours; the former without Metro, the latter with.

Hackers Don't Need Permission

Michael August Pusateri, reacting to Kyle Weins’ lament about the upgradeability of the new MacBook Pro:

To ask that every piece of modern electronics is designed to allow the tiny fraction of hackers to upgrade is the height of hubris, unreasonable, and a huge imposition on everyone else that has no desire to ever crack the case. 

[…] Hackers, hot rodders, and makers will always find a way to do what they want, but it shouldn’t come at the expense of everyone else that simply wants a good, reliable product.

Hackers don’t need approval, acceptance, encouragement or permission. They need what they’ve always had; curiosity.

Slow Web

Jack Cheng:

Timely not real-time. Rhythm not random. Moderation not excess. Knowledge not information. These are a few of the many characteristics of the Slow Web. It’s not so much a checklist as a feeling, one of being at greater ease for the web-enabled products and services in our lives.

It’s interesting how many of the web-enabled things I use and value fit into this category.