Good Will Blogging

Remedy: Inconsistent Bluetooth headphone volume

Wed, 22 Feb 2012 21:24:00 +0900

I’ve been having a problem with Bluetooth headphones on my iPhone 4S (iOS 5.0.1), where sometimes the volume, even when turned up to maximum, is very low. Sometimes it seems to fix itself, but other times, I couldn’t fix it even by rebooting the phone and the headphones.

Although this doesn’t fix the problem permanently, I have found the following to be the quickest way to reset the volume to the normal level:

Just go to the camera app while audio is playing, and switch to video capture mode. For some reason, this stops playback. Close the camera app and resume playback. Audio volume should be back to normal.

I have no idea why this is happening, or why the above method fixes it. Hopefully this is helpful to someone, if not just to me when I forget how to do this for the fifteenth time.

;)

Apple Tick Tock

Wed, 22 Feb 2012 21:15:22 +0900

Listening to @siracusa’s podcast, he prescribes an interesting solution to the problem he perceives with OS X moving to a yearly update schedule: Intel’s tick-tock model.

It certainly seems to fit with Apple’s behaviour in recent years.

Exhibit A: iPhone

The iPhone 3G, a big update to the original iPhone, was followed by the relatively modest 3GS. It had an identical external design, and even its name acknowledged that it was intended as a better iPhone 3G.

The next update, iPhone 4, was clearly a “tock” — radically new design, and big improvements across the board. And again we saw the “tick” as iPhone 4S, similar to iPhone 3GS in both the magnitude of changes and the naming. iPhone 4S is an iPhone 4, plus an S. It is the iPhone 4 that has become logistically practical to manufacture in 2011/12.

Exhibit B: iPad

Okay, we haven’t actually seen the third episode in the iPad saga yet, but I’m convinced it will be a “tick” — a refinement on the current iPad 2 design.

Certainly the iPad appears to be following the same pattern as iPhone for its first two designs. We shall see.

Exhibit C: Mac OS X

As Mr Siracusa points out, Snow Leopard was a functionally minor increment over Leopard, as Apple focussed most of its resources on stability, performance, and architectural improvements.

What he didn’t mention, unless I missed it, was that its name was an increment of its predecessor. Just like the iPhone 3GS, just like the iPhone 4GS.

And here we are again, with Mountain Lion. If I’m right, its name intentionally signals a “tick”, meaning it is intended to be a better Lion. If I’m right, we can think of 10.8 as “Lion S”.

From what I’ve seen of it so far, it does appear to be functionally minor. The headline features touted on Apple’s teaser page are almost all existing features of iOS, so really, there isn’t much new design work there. Think back to Snow Leopard — it wasn’t completely devoid of new functionality; there was actually quite a lot. I think Mountain Lion is approximately on par with Snow Leopard in terms of the visible stuff.

All of this is meant to support the case for 10.8 as a big stability and performance release in disguise. Is this wishful thinking?

"See iTunes for more information"

Sun, 12 Feb 2012 08:43:00 +0900

iTunes Sync 2 items could not be synced. See iTunes for more information.

…But iTunes appears not to show any information about this error. And it keeps happening. And it seems a lot of people are having the same problem:

Well I figured it out, so I’m posting it here in case I forget later. Hopefully it’s also useful to you as well.

There’s a little, almost invisible warning symbol that shows up in iTunes next to your iPhone:

Click that, and you get this pop-up window, which tells you which files couldn’t be synced, and why:

So to stop the error, you can either fix the problems it describes, or check the “Do not warn me again” checkbox. (If you do, and you want it back, right click your iPhone in the sidebar and select “Reset warnings”.)

You’re welcome.

iPad 2S

Sat, 07 Jan 2012 13:31:00 +0900

The next iPad will not be iPad 3. It will be iPad 2S.

Apple has established the pattern already with iPhone: after the original iPhone, there was a significant external hardware design change in the second generation, iPhone 3G. The third generation iPhone retained the exact same external hardware design as the second generation, and got the name “iPhone 3GS”. This was repeated with the new design of iPhone 4, inherited by the iPhone 4S.

The first generation hardware was not repeated, and served almost as a prototype. From the second generation, the hardware design lasts two product cycles — two years.

I would not be the first to speculate that this is related to the costs of manufacturing machinery and processes. Apple sees its competitive lead as being more than 2 years anyway, so why waste resources re-tooling its plants every year?

So far, the iPad seems to be following the same pattern: the second generation got a significant external hardware design change. Apple’s product naming strategy for iPad may differ from iPhone, meaning Apple may choose to name the next iPad “3”, but I predict the external hardware design will be exactly the same as iPad 2.

Note that this does not discount the possibility of a Retina Display. A double-resolution display does not affect the external design. It will certainly require different internals, but I’m only talking about the external design here — both the iPhones 3GS and 4S had huge internal upgrades.

So here are my predictions for the next iPad, just for fun:

Name: iPad 2S.
Form factor: Exactly the same as iPad 2.
Screen: 9.7-inch diagonal; 2048 x 1536 resolution at 264 ppi. (This will qualify as “Retina Display” by way of typical viewing distance.)
Storage: 32 GB, 64 GB, and 96 GB.
Chip: Next-gen (“A6”?) dual-core SoC; improved graphics.
Cameras: At most, a modestly improved rear camera.
Software: Siri support; a point upgrade to iOS, probably “5.2”; more iCloud-based features; and at least one new feature that doesn’t work outside the US.
Release date: 16th March, 2012.
Price: USD $499 for 32 GB WiFi model; $829 for 96 GB WiFi + 3G model.

UPDATE: Since iOS 5.1 still hasn’t been released, I expect it will with the new iPad announcement. Also, it looks like the new chip will be named “A5X”, which leads me to think the name of the new iPad will be “iPad 2X”.

Ocean, Trust

Sun, 27 Nov 2011 19:11:40 +0900

On his podcast with Dan Benjamin The Talk Show, episode #68, John Gruber said, of the way he views the Kindle Fire’s competitive position relative to the iPad:

The Fire is way more interesting, because it’s not an iPad rip-off. I mean, clearly it’s following the path that the iPad blazed in terms of basic form factor, and that the key to tablet computing is touch-based interfaces. It’s not the previous Microsoft style of styluses and full Windows operating system.

He’s right, of course, but what I anticipated him to say was, “The Fire is clearly sailing in the iPad’s wake, but that’s not to say they’re copying iPad.”

The truth is, as everyone knows, Apple didn’t invent the tablet computer. Microsoft didn’t invent it either, but they were the first to bring an actual product to market (AFAIK) with the Windows Tablet PC.

But the Tablet PC didn’t catch on. It didn’t leave a wake for others to follow. To stretch the boating metaphor, it was like a cargo ship scraping its hull on in too-shallow water.

The iPad followed the Tablet PC’s path, but it sails in deeper water — water that wasn’t there before. Apple brought the ocean.

And now the ocean is there, the Kindle Fire has an ocean to sail in. What we haven’t found out yet is, are they another boat in iPad’s wake, or just waterskiers?

Later in the podcast, Gruber makes the point that quite possibly zero people who have bought a Kindle Fire were first-time Amazon customers:

That you can say, ‘Look, if you trust us, and you already have an account with us…’ And I can’t help but think that almost everybody… I mean how many people do you think have bought a Kindle Fire, who didn’t already have an Amazon username and password? I mean, maybe zero! It might literally be zero people who’ve done that.

Thinking about what makes the Kindle Fire the first credible competitor to the iPad, it occurs to me that Amazon and Apple both have an immeasurably valuable asset to their names: millions and millions of credit cards.

Once a company already has your credit card details, it is so much easier for them to get you to give them money. This is obvious, but to finish the point, the user experience of entering credit card and shipping address details is long and painful. You have to type a lot of personal details into the website of a company you just met, and any mistake might mean you don’t get what you want, or worse, lose some money.

To flip it over, the point is that every account they have, with credit card details, is an expression of trust from the customer. Credit Card = Trust. You are already in business together. The asset that both Apple and Amazon have is the trust of millions of people.

And it’s all about trust. Amazon was the first truly successful retailer on the Internet. They basically invented online commerce. They had to invent a lot of the technology that allows us to use credit cards — a hopelessly insecure technology conceived in simpler times — on the new world of the Internet. When it comes to using credit cards online, Amazon brought the ocean.

Apple started building its stockpile of credit card accounts much later than Amazon, with the iTunes Music Store. And they leveraged the trust they had earned from making stuff that “just works” to add more accounts with the App Store. Steve Jobs quoted the number of accounts a few times in keynotes, particularly at WWDC, to encourage developers to write more apps, which sold more iPhones and iPads, which got them still more credit cards. This feedback loop has generated a great foundation for Apple to sell things to people, and it’s probably not even 10% of Amazon’s credit card accounts.

If credit cards are a proxy for trust, or at the very least a gateway for digital commerce, then what other companies have this? Seriously — who else has as many credit cards on file as Amazon and Apple? Nobody, right? Certainly not Google, and probably not PayPal, either.

If you stop and think about that, it implies a potential for almost all digital commerce to go through Amazon and Apple. That’s an incredible prospect. And it’s why I expect Apple to enter the market for ad-hoc payments. Maybe NFC, maybe something like Square, maybe something more like EasyPay, maybe something totally different.

But no company can do that without Trust. So the only question is, will it be Apple or Amazon?

GTD Rebirth Cycle

Sat, 19 Nov 2011 09:35:50 +0900

Phase 1. Use a GTD system. It works well. Things are getting done, nothing is being forgotten, and you’re feeling less stress. Life is good in Phase 1.

Phase 2. You grow confidence in your system. So much confidence that you throw new tasks into it with giddy abandon. Adding tasks to the system starts to give you the same feeling of accomplishment as actually completing the task. (This is obviously wrong, and the first warning sign.)

Phase 3. Tasks are going into the system much faster than they’re coming out. It starts to grow out of control. The number of tasks becomes overwhelming, and you resist looking at them.

Phase 4. You try to regain control by “organising” the system. You make categories and special lists. You associate actions to projects. You invent new disciplines for yourself to “keep things organised”.

Phase 5. The work required to keep the system up-to-date starts to exceed the time spent on the actual tasks it tracks. Now you feel it’s not working. Something has to change.

Phase 6. You notice an article or an ad for a “simple”, “clean”, and/or “powerful” to-do manager. You think, “That’s what I need! This system I have now is too complicated, too hard to use.” And you switch. Maybe you figure out a way to export all your projects and actions from the old system and import them to the new. Or maybe you decide to “start fresh.”

Repeat from Phase 1.

I’ve personally been through about 7 or 8 different GTD systems. That’s 7 or 8 times through the cycle above. I know it well. And I just completed Phase 6 again this week.

As a future reference for myself, more than anything else, here are some thoughts on what makes GTD tick — what makes a “good” GTD system.

First, and most important, GTD is a process of thinking, not a system or a tool.

A couple of years ago, I heard an interview with one of the “coaches” from the David Allen company, talking about her experiences teaching GTD. She said that often people will ask what’s the best tool to keep GTD lists, or complain that they really like their Filofax, or their Outlook, or their Post-it notes. She would say, “That’s fine! I can teach you how to do GTD on Post-it notes.” Her point being that GTD is about thinking what is the next action, and relieving your brain of the burden of having to remember so much stuff.

So it really doesn’t matter what your tools are. In fact, I’ve found that the tools can actually get in the way, because they distract me from the really important job of thinking.

Second, don’t invent parts of GTD that aren’t really there.

A classic and very common example is association between projects and actions. It’s so common for GTD tools to offer a way to link projects to actions, that many people I know think that it’s part of GTD. It is not. This is like that Real Monopoly meme. Go back and read the GTD book again — it’s not in there. There is even specific advice not to try to link projects and actions. You just need a Next Actions list, a Projects list, and that’s it.

The rationale for this is that if the project is current, the action real, and you are doing your Weekly Review, you will know which actions relate to which project.

Having learned this lesson once already, I again fell into this trap while using Flow. I am now convinced that trying to link projects and actions is death to a GTD system. Having actions tucked away in project lists just keeps them out of sight, out of mind. And it hides the true size of your system. Keeping your lists short should be part of the motivation to get things done, and to not over-commit yourself.

Third, use the Someday/Maybe list aggressively.

When you find yourself with a bit of time, scanning your actions list to find something you can get done, you should be able to complete any action on the list. If you look at an action, there can only be three possible reasons why you can’t do it right now:

It needs a context, either a place or a person, to get done. If this is the case, you should really annotate the action with that context right away, so you don’t go through this again next time.
It’s not really a next action, i.e. you haven’t done enough thinking to boil down the next “physical, visible thing needed to move the situation forward.” If this is the case, do that thinking now, and replace this action with the real next action. Then do it.
You don’t want to do it. If you don’t feel motivated to complete the action, and it’s not because of the two reasons above, then either delete it and forget about it, or move it to Someday/Maybe. (This also applies to projects.)

The goal here is to keep your Projects list and your Next Actions list as short as possible. They should be a list of things that you are really motivated to complete. Looking at these lists should get you excited, not make you groan.

Moving something to Someday/Maybe is not throwing it away, so long as you commit yourself to reviewing the Someday/Maybe list regularly, about twice per month or so. Of course, when you do, delete things that you recognise will never happen — you don’t want that list to become overgrown and full of useless crap, either.

Fourth, no metadata, no notes, just things on lists.

Another bad habit encouraged by all these GTD tools (especially electronic) is adding all sorts of tags, due dates, priorities, notes, etc. The best GTD system I ever had was paper-based. I really encourage people to try running a non-electronic GTD system for a few months. The nice thing about paper-based systems is they resist a lot of metadata cruft. You can write down due dates, tags, priorities, etc., but it’s a lot more effort, so you don’t so much.

This is how it should be, even when using an electronic tool. The occasional due date or priority highlight is fine, but over-reliance on them dilutes their meaning, to the point of becoming a waste of time.

Fifth, don’t get too hung up on contexts.

I’ve never found it helpful to keep separate lists for each context, mostly because there would just be too many of them, and again, having a lot of lists means actions are hidden and easily forgotten.

It’s best to just keep one big list of all actions (or two, if you use “the line”), and note your contexts at the beginning of the action, e.g. “@Dad — ask about ideas for Mum’s birthday present”. It works well for both paper and electronic systems, because you either scan down the list visually, or just search for “Dad”.

And anyway, what are those contexts? For me at least, there’s @Home and @Office, and maybe @Shops, and the rest are people. And since most actions in “people” contexts can be accomplished by phone, email, or text, they can actually be done anywhere, anytime. So don’t spend a lot of time adding contexts. Add them only when not being in a context prevents you from completing an action here and now.

Finally, GTD is about getting things done.

Any time spent fiddling with the system is time not spent completing actions. Behind every minute spent “organising” the system, is a reason why you’re not motivated to complete the actions in there. Find that reason. Figure it out. Move forward.

Future of Siri

Mon, 14 Nov 2011 11:50:16 +0900

The API for developers to interact with Siri will be in the cloud.

Siri requests are processed in the cloud, so the shortest path from Siri to apps is within iCloud.

This will require apps to be integrated with iCloud. Siri API will be a part of the iCloud API.

How this could work:

An iPhone user speaks to Siri.
Siri in the cloud deciphers the user’s speech, and figures out that the user wants a service from app X.
Siri invokes the iCloud API of app X. App X responds with some text, an image, and/or a URL that their iPhone app has registered.
iCloud returns this data to the iPhone, and Siri speaks the text, displays the image, and/or jumps to the developer’s app on the device.

What I haven’t figured out yet is how developers will register their apps to be invoked for certain phrases. Seems incredibly broad. And how will competing apps register to receive the same invocations?

It’s going to be very interesting.

How to Work All Day

Sun, 25 Sep 2011 18:03:53 +0900

I’m trying a variant of the 30/30 Work Cycle for days when I work by myself, without the distractions of meetings and random interruptions. So far, it seems to work fairly well, especially when motivation is a bit low and the work takes a lot of concentration.

My variant goes like this:

Set a timer (on iPhone, in my case) for 25 minutes.
Work on something hard until the timer goes off.
Take a minute to jot down notes on whatever thought you were in the middle of.
Stand up out of your seat, walk around, stretch, jump, whatever. Just get the blood flowing and the heart rate up.
Repeat from 1, choosing a very different task to the previous one.

I have noticed a few nice benefits to working like this.

First, getting up and moving my body about twice per hour seems to help a lot with the lethargy that usually comes from working at a desk all day.

Second, the context shifts keep everything feeling fresh. Motivation is a lot easier when I know I only have to concentrate on this task for 25 minutes, especially for tasks I’ve been avoiding. And, it’s amazing what can be achieved in only 25 minutes.

Third, it stops the opposite problem, where I get too engrossed in a task that is easy and/or fun, but ultimately not very important.

Fourth, when I have something I want to do, and something I know I should do, I don’t have to choose. I can do both! (Pro tip: always do the “should” task in the first 25-minute session.)

I’ve found that with this method, I can work for many hours (my record so far is 12!), without falling into lethargy or fatigue, with 50 out of every 60 minutes spent in concentrated, productive work.

I found a handy list of iOS release dates, including beta...

Sun, 07 Aug 2011 18:05:02 +0900

I found a handy list of iOS release dates, including beta versions, on Wikipedia. So I made a Numbers spreadsheet to show the longevity of each version. Here ‘tis.

Notes:

I didn’t include the iPad-only versions, as it would mess up my calculations of how long each version was in Final.
For some reason, the iPhone OS 2.0 beta 1 release date is not listed, so I entered the same date as beta 2.

ISO... Pffft!

Tue, 26 Jul 2011 18:39:57 +0900

I like standards. Standards are good. Except when they’re stupid.

A while back I found myself about to argue that the Japanese date format (yyyy/MM/dd) was the international standard, followed by a long spiel about why it’s better. But I thought I should check my facts first, and a quick search in Wikipedia found this: http://en.wikipedia.org/wiki/ISO_8601 The tl;dr summary is, the ISO date format is yyyy-MM-dd.

Close enough though. My argument was going to be that the year-month-day format has 2 big benefits:

The units are in size-order. In this case, it’s big-medium-large, but the opposite order, eg. Australian (and presumably UK) format is dd/MM/yyyy, is just as valid for this criterion.
Having the biggest unit at the left makes it useful as a sort order. (In this case, ISO and Japanese formats are optimal).

After thinking about it for a while, I found that the ISO format’s use of hyphens instead of slashes as the separator also has some benefits over the Japanese use of slashes:

Hyphens are less distracting visually, making it easier to quickly read the component numbers.
Slashes are not very different to 1’s, whereas hyphens are not similar to any digit.
Slashes can’t be used in file or directory names. Hyphens can.

So far the ISO standard format sounds pretty good, right?

That’s dates, so how about times? According to ISO 8601, the standard format is hh:mm:ss. This is fine, and pretty much expected. However it does have a couple of problems:

The colon character is generally not allowed for file or directory names.
The colon is a little bit too close to digits in visual density, making it a little bit harder for the reader to find the component numbers.
No singular standard for sub-second precision.

OK, so not ideal. But not stupid. So what’s stupid?

It’s the part of the standard for combining a date and a time into a date-time stamp. The ISO format is yyyy-MM-ddThh:mm:ss, eg. 2011-07-26T13:46:15.

WTF?! T???

“T” is a terrible delimiter. It has the same visual density as the digits on either side, making it harder for the reader to see where the date ends and the time begins. The example above looks like it’s made up of two parts, “2011-07” and “26T13:46:15”.

Worse, I’ve never seen “T” used as a delimiter in this way outside of the ISO format. At least with date and time, “-” and “:” have been commonly used as delimiters. So the “T” is foreign to everybody.

You know me. Faced with this anomaly in the universe, I feel compelled to appoint myself as a committee of one to fix the fracking international standard for date/time formats. Here goes.

Date: yyyy-MM-dd
Time: hh.mm.ss.SSS
Datetime: yyyy-MM-dd..hh.mm.ss.SSS

(The “SSS” can be extended to as many digits as needed. The sub-second and second components are optional.)

The benefits of this format are:

The units are in big-to-small order.
It’s easy to locate the component parts visually, and date and time are more separated than their internal component parts.
It can be used for file or directory names.
As a bonus: it can be typed entirely on the ten-key keypad with one hand on a standard PC keyboard, with no chording.

The disadvantages of this format are:

It’s one character longer than the ISO format, but I think this is an insignificant difference, and worth it for the visual clarity. A space character can be used in place of “..” in situations where a space character is permissible.
Using dots in the time format is less common than the colon character, but I think it’s ultimately better, and not difficult to understand.

What do you think?

The honeymoon suite. (Taken with instagram)

Fri, 08 Jul 2011 22:53:12 +0900

The honeymoon suite. (Taken with instagram)

On Apps, Docs and the "Death" of File Systems

Sun, 12 Jun 2011 15:57:25 +0900

In iOS, Apple hid the file system completely from the user, making apps the main way users find their documents. From the murmurs we’ve heard from WWDC attendees last week, it appears Apple is now preparing to do the same thing to Mac OS X.

If my memory serves me, this is not the first time we’ve had an app-centric OS. Windows was also app-centric in the beginning. Although Windows users were exposed to the file system, the Program Manager presented a grid of app icons, so we were encouraged to open Word and choose File > Open, or File > Recent. What I saw of Macintosh System 9 was similar.

Starting with Windows 95, the app-centric model was turned on its head. Applications were relegated to the Start Menu in the corner, and the user was presented with a large Desktop which could hold document files. Take a look at most Windows users’ desktops today and they are covered with a grid of mostly documents. Users are encouraged to not think about which application they needed, but simply find the file they want and let the OS open the right app. Mac OS X is essentially the same, with the exception that applications get a little more love in the form of the Dock.

So to me, this return to an app-centric style feels cyclical. I tried to express this in a tweet the other day:

Design app-centric OS.

“Which app did I create that doc in?”

Design doc-centric OS.

“Where did I put that file?”

Repeat.

I think we are just seeing the latest iteration of what may turn out to be a circular, fruitless search for the best way to associate applications and documents. Neither doc-centric nor app-centric approaches were a good fit for the user model.

Among the chatter on this topic recently has been a consistent theme: File systems are fine for nerds, who have learned them through experience, but not for casual computer users (aka normal people). I’ve heard the same argument made for the mouse-based GUI. In both cases, it would appear iOS has solved the problem by removing it. No file system, no mouse.

OK then, if this is just cyclical, eventually we will once again think of app-centric as confusing, and doc-centric as the way to go, right? But that’s still wrong, because otherwise how would we be here today, praising the virtues of an app-centric approach!

Yes and no. The problem with the last iteration of the doc-centric approach was that it was all about the file system. Every modern desktop OS today comes with a search tool (Windows Search, Spotlight, etc.) because finding documents in a file system is hard. But ultimately search tools are just a bad and often ineffective patch over an already broken UI: the system model (file system) does not match the user model.

So if the user model is not doc-centric or app-centric, what is it?

Good question. I don’t know. My guess is that the best choice is to mix both an app-centric approach, with doc-centric features like the following, without exposing the file system to the user.

Project-centric
Context-centric
History-centric

Project-centric — Let’s say you are working on a project to select from a few different software packages. You need a spreadsheet document to compare numbers and feature lists, some PDF documents containing the official quotes from the vendors, and a presentation of your recommendation to management.

All of these documents open in different applications, but they are associated, mentally, with the software selection project. The file system solution for this is to stick all the document files into a directory together, with the name of the project as the name of the directory. This is convenient, because you know you can go to that directory and have everything you need to work on the project. You don’t need to know or care which apps you used to create/read these files.

The problem with using the file system to implement the project-centric idea is that it’s easy to forget where the directory is — and more importantly, for most non-nerds the concept of a directory is alien to begin with.

The solution may be keywords (aka tags, labels). Don’t expose the file system structure to the user, but strongly encourage them to add keywords to their documents. Instead of asking for a filename on save, ask for keywords, and make it insanely easy to use keywords that have been used before.

Even entering keywords can be a pain, so maybe the OS could reduce the need for it by automatically picking up frequently-used words from the document to suggest keywords. If a human can look at a file and figure out some appropriate keywords, it would probably not be too difficult for some heuristic algorithm to do so.

Context-centric — The OS could track which documents are accessed in close temporal proximity to each other, and automatically guess that they are part of a project or workflow. If Document A and Document B are frequently accessed within a few minutes of each other, the OS could make it easy to jump from A to B and back again.

To make this more explicit, users could be prompted to associate A and B when this happens: “Is this document related to A? [Link Docs] [Not Related]”.

Taken further, the OS could look deeper into the content the user is working on, and attempt to make some intelligent guesses based on their context.

History-centric — I would guess that the vast majority of work on documents happens within a relatively short time range, and therefore documents that the user needs are almost always in top 50 most recently accessed docs.

A good UI for quickly jumping to very recently accessed docs might take us 80% of the way there.

Don't press the handicap elevator button

Sat, 14 May 2011 14:05:08 +0900

(I’m talking about elevator ranks that have two buttons to call the elevator, and one of them is marked with the handicap symbol.)

I always thought people who press both buttons were just inconsiderate, but it seems that many people don’t actually know what that button does, so this post is to enlighten anyone you know who does this.

The handicap button is a feature of elevator systems where there is more than one elevator, but not all of them have accessibility features for the handicapped (a mirror at the back, a second set of lowered buttons, etc.) Handicapped people need these features to ride the elevator, but where they are not installed in every elevator car, the special handicap elevator call button makes sure they get one.

For example, if the rank has four elevator cars, often only one of them has accessibility features. If you press the handicap call button, only that one will arrive. If you press the “normal” call button any one of the four may arrive.

But if someone presses both call buttons, depending on the timing and other factors, two elevator cars may arrive, one after the other. One of them will be the handicap car. The offending button-pusher will get in the first one, and not see the second one arrive. Perhaps this is why they don’t realise how this works.

Ever been in an elevator, and it stops at a floor but nobody gets in or out? Confusing and annoying, right? Makes the elevator ride take longer than it needed to, right? Most of the time, it’s because someone pressed both buttons.

For 99% of people who press both buttons, this will be reason enough to stop doing it — that they didn’t realise they were inconveniencing others. Unfortunately, 1% will still think it gets them an elevator faster. It doesn’t. In fact, it makes the whole system slower for everyone.

It is natural to assume that the algorithms that control elevator movements is designed to minimise waiting time and maximise passenger convenience. Not the case. Elevator algorithms are designed with one thing in mind: power. Elevators use a lot of power, which is expensive. Passenger convenience is of secondary importance.

So when someone presses both buttons, calling two elevator cars, the system reacts by finding the most power-efficient way to handle what is supposed to be a relatively rare occurrence, i.e. an able-bodied person called an elevator, quickly followed by a handicapped person. When that happens, passenger convenience goes out the window (er, down the elevator shaft?)

Since many people press both buttons every time, imagine how much better your elevator rides would be of everyone stopped doing this! (Hint: Pass this on.)

John Resig - Learning from Twitter

Mon, 09 May 2011 20:29:57 +0900

John Resig - Learning from Twitter:

(via Instapaper)

Flow — Update 3

Sat, 30 Apr 2011 22:18:00 +0900

After Metalab made collaboration with non-members free, it suddenly became feasible to use Flow as both my main GTD system in anger, and as a team management tool. I signed up for $10/month and have been using it for the past couple of weeks.

All I can say is “wow.” I never expected it to be so good. It’s very subtle, but there is something about Flow that makes it the first really successful GTD system I’ve ever had.

I have used many many GTD apps in the past, with varying degrees of success, but the most important thing about maintaining a GTD system is to keep it up-to-date and fresh. The problem with all the iPhone apps I have used until now is the lack of a strong desktop solution.

It doesn’t matter how good the iPhone app is, when I’m at my desk processing email, stopping to capture an action in my iPhone is too disruptive to the workflow, so it doesn’t happen.

I’ve tried apps that also have a desktop companion product, like Things and OmniFocus, but they are Mac-only which means I can’t use them at work. And to be honest, both are pretty terrible desktop apps.

So the first and biggest benefit of Flow is that the web app looks and feels like a desktop app, but I can use it exactly the same way on Mac or Windows.

I don’t know what is taking the Cultured Code guys so long to implement cloud sync for Things — judging from their blog they seem to be really over-thinking and over- engineering it. OmniFocus had a reasonably good cloud sync over 2 years ago, and Metalab seem to have perfected it in Flow.

Flow’s sync has all the properties you would want in a cloud-based sync solution: it’s fast, automatic, and reliable.

And man is it fast! It happens in the background in the iPhone app, so you probably wouldn’t even notice if it was slow, but it is usually finished in a few seconds.

I don’t know for sure, but it seems they have achieved this by making the sync incremental in such a way that it doesn’t need to sync its entire database every time, just the particular list or task that you are viewing.

I have sat in meetings with people in my team, and assigned a task to them on my iPhone, and a few seconds later it shows up on their iPhone. There is a palpable sense of transfer of responsibility when I do that, which has made a noticeable difference to productivity.

Flow has a very simple, bare-bones approach to GTD — in fact, it is not specific to GTD at all. They even renamed “projects” to “lists” to erase any trace of the app imposing a particular methodology on the user. I am a GTD guy, and it works perfectly as a GTD app.

I think the only “pure” GTD feature missing is the “tickler”, which was implemented in Things as “scheduled tasks.” But, to be honest, even as a GTD purist, the tickler is too often an invitation to procrastinate. I don’t miss it.

As I’ve noted before, sometimes just changing my GTD system is enough to motivate a period of great effectiveness, so I must acknowledge that this could be just another case of “a change is as good as a holiday.” We’ll see.

Flow — Update 2

Sat, 09 Apr 2011 06:01:14 +0900

So Metalab, the people behind Flow, have just announced free collaboration with non-members.

Metalab:

Today, we’re making it even easier to collaborate with anyone in your life. From now on, when you delegate a task to someone who hasn’t signed up, they’ll receive a personalized link to the task instead of a generic invitation to Flow. They can respond to comments, complete tasks, and view all of the tasks they’ve been assigned—all without signing up. And best of all, it’s totally free.

This is the key change that makes is possible to seriously consider moving to Flow permanently. Now, I don’t have to worry about the huge cost to have my whole team on Flow. Even if I am the only paying member, I can still use it to delegate tasks to them and get their updates. (That’s all I really need for my own purposes.)

In fact, it might even be better. I’ve found that Flow can be a little too promiscuous when it comes to sharing lists with collaborators. If you add a person (who is fully signed up) as a collaborator to a list/project, tasks you add for yourself appear to the collaborator as a task for them. Effectively, they are everyone’s tasks. A couple of times already, someone else has marked as completed a task that I was planning to work on myself. It seems that when you have others collaborating on a list/project, you have to explicitly delegate to yourself if you don’t want them to work on it.

Although they are still ahead in terms of some features, I think Things has some catching up to do here. They have a Mac version, but Flow has the edge in that their desktop (web) app works anywhere. That is a huge advantage if you want to access your task lists from home and work, especially if you are forced to use Windows at work. To be honest, although it is a little slow, the Flow web app is actually ahead of Things for Mac in terms of UI & UX in my opinion.

Flow — Update 1

Tue, 05 Apr 2011 05:22:04 +0900

As soon as I went back to Things I immediately noticed probably the most compelling thing about Flow as a personal GTD system: the ability to use it on the desktop (via the web UI) at work (Windows). It was jarring to have to suddenly go back to picking up my iPhone while processing email in the morning just to enter an action item.

I realised that with Flow, I’ve got a desktop app on both Windows and Mac, an iPhone app, and I can also use it on iPad if I want, all cloud-synced, and I don’t have to worry about the company firewall. That’s actually pretty compelling.

So this morning I decided to just sign up for myself, on the month-by-month plan, to evaluate it for a few months as my personal GTD system. I’ll also tell my teammates that if they choose to join me, to let me add them to my account so we get the volume discount if enough do.

This is an experiment, which is why this post is titled “Update 1” — I’ll be back with the results in a few months.

Flow

Sat, 02 Apr 2011 23:16:51 +0900

I’ll admit to jumping on the bandwagon of pretty much any product that has a promo video by @lonelysandwich. I also have a GTD/to-do app addiction, so when I saw this video for Flow by Metalab, it was a forgone conclusion that I would sign up.

What interested me most about Flow is its collaborative nature. Right from the promo video, they are very clear that collaboration with others is the primary benefit of Flow. I was also impressed by their web application. No need to install a desktop app, no worries about whether it’s Mac-only or Windows-only.

I sent the link to a few people in my team at work, and everyone signed up. (I think they thought they had to, because I’m their boss… hmmm.) Anyway, I started assigning tasks to them and inviting them as “followers” to some of the projects I created.

As a GTD/to-do app, it’s not bad. It uses tags, exactly like Things — which I’m now convinced is the future for all apps that help you organise lists. It has projects and folders, it automatically clears away completed tasks after a day, etc. Not quite as feature-complete as Things, but the fundamentals of a GTD app are there and they are solid.

But wow — the collaborative features elevate the experience almost to what you might call “Social GTD”. Each task allows a thread of comments, which steps almost into the realm of a bug tracker (in fact, it would make a pretty decent bug tracker). It’s actually kind of fun to organise projects and pass them back and forth between members of the team.

It is also very useful to have the iPhone app, which syncs with the cloud over the air, for use in meetings. A couple of times, I was in a meeting with the Business and was able to send a task to a member of my team as it came up. Pretty cool.

But it’s not all paradise. (At least not yet.)

First, there’s the price. USD $9.99/month or $99/year, with volume discounts that go down to 50% for a team of 10 or more. Now, I do believe in paying a fair price for quality services, and a hundred bucks a year isn’t that much money, so I could see maybe spending that for myself, if it had some features that made it significantly better than Things or OmniFocus for personal use. Right now, it does not.

The problem is that Flow’s main selling point is its collaboration features. So to make it worthwhile, you would have to get all the people in your team to become paying members. Assuming your company doesn’t pay, you either fork over hundreds of dollars yourself, or somehow persuade everyone you work with to pay $100/year out of their own pockets.

Second, there’s the apps themselves. Both the web app and iPhone app are attractive — the web app in particular is pixelicious — but not quite there in terms of usability and performance. The web app often has a big lag before a click takes effect, and switching views can take up to a few seconds, even with small lists. The iPhone app is functional and pretty, but syncing is slow (and often has to be initiated manually), and there are no push notifications so you have to rely on email or checking the app repeatedly for updates.

In conclusion, I think Flow has made a good start here, but the price point is too hard to get on board with a whole team, even giving them the benefit of the doubt that the functionality will improve in the future. I will definitely keep watching them to see how they evolve, but for now I’ll be migrating back to Things and hoping against hope for their cloud sync to arrive.

"the first 90 percent of the work is easy, the second 90 percent wears you down, and the last 90..."

Tue, 29 Mar 2011 10:18:21 +0900

“the first 90 percent of the work is easy, the second 90 percent wears you down, and the last 90 percent - the attention to detail - makes a good product”

- Graphing Calculator Story

Another New Market (Apple's subscriptions API)

Sun, 06 Mar 2011 13:22:20 +0900

I’ve let this subscription stuff swirl around in my brain for a week or so while reading the arguments on various sites. There have been a few really well-thought-out articles, but I feel there is an important point that’s either missing or way under-represented.

All of the opinions I’ve read seem to focus on what it does to existing business models. But there has been very little focus on what new business models are now possible, that were impossible (or at least difficult) before.

For example, until now, a feature writer had I guess two options to make a living: an ad-supported weblog, and/or syndicated writing for a magazine, newspaper or website. But now there’s a third option: make an app that delivers your writing to paying subscribers.

I, for one, would happily pay for a subscription in a Daring Fireball app.

Of course, it’s not only writing that could take advantage of this business model. Imagine, a photographer delivering her work to paying subscribers, a language-learning app that delivers lessons, even a special-interest club that uses the subscription payments system to collect membership fees.

And the important thing is, this model is now available to anyone at any scale. The size of Apple’s 30% cut is largely irrelevant for people who didn’t have a viable business model before this. Getting 70% of something is better than getting 100% of nothing.

The App Store did this first. How many iOS developers out there now find themselves in a new career, being their own boss, having fun and making their own money? Mobile wasn’t new, software wasn’t new—and yet the App Store created something new that has changed the course of many, many people’s lives. A similar revolution is now possible for new businesses to sell their content/service on a continuous basis as micro-subscriptions.

One of the really surprising things that emerged naturally in the App Store was the extremely low prices. Of Apple’s own strategy to sell devices, Steve Jobs said at the D8 conference:

“Price aggressively and go for volume. That worked for us.”

What’s amazing is, that strategy is now available not just to big corporations, but to individuals working in their underpants at home. Many, many developers are earning steady income from sales of their $0.99 apps.

But one thing about this phenomenon had troubled me: iOS apps are a one-time sale. Because of the lack of upgrade pricing in the App Store, developers face a market saturation problem. All their revenue comes from new customers only, who find their app through word-of-mouth, reviews, and search results. But if you have sold your app already to everyone in your target demographic, the revenue stream would theoretically stop. You have to either do the Tweetie 2 thing and release a new app (and deal with all the consequences of that), or expand your product line by developing other apps.

In-app purchases may have helped a little to improve the situation, but there’s a psychological barrier that must be overcome every time the user is presented with a “Buy now” button. With both IAP and App Store purchases, the developer must overcome that barrier every time to get paid. But with subscriptions, they only need to overcome it once to produce a steady stream of income. That’s huge.

Think of it this way: when a person buys a mobile phone, they see two prices - the price of the phone, and the monthly plan price. But how many people multiply the monthly plan price by the length of the contract, as part of their purchase decision? There is a very low psychological barrier to recurring payments. So, if you have valuable content to deliver to your users via an iOS subscription app, you could price it at $0.99/month or even $0.09/month and build your business based on a steady, predictable income flow.

For some, that may turn out to be the last incentive they need to quit a job they hate and strike out on their own.