kzeise.com

Dave Addey has written a nice piece about App Store pricing. The pricing is not much of a problem with games, where Apple allows developers to make progress painfully slow unless you regularly fork over some money: Real Racing 3 is such an example.

Productivity apps should copy this model, and ask for gold for every document you create. Then give everyone one free document, and offer 5 document, 50 document, and infinite document packs as IAP options. Or for your social apps limit the amount of people you can connect to. The few apps that do not fit are either conceptually simple enough that you can make a convincing video demonstration or they live off data for which you can sell a subscription.

Interestingly Apple permits quite a bit on the App Store which I regard as clear violations of the developer agreement: in game currency violates section 2.1 of the IAP addendum (it is a prepaid account), the Perspective app violates section 2.3 as a subscription service. I suspect these are a symptom of Apple looking to allow people to make money, and hopefully will mean some official changes coming in the future.

There is also a more fundamental problem in app discovery: The App Store is so large that it is quite hard to find what you want. What you want in addition are curated stores that only carry the best software, say one for teaching science. They should not replace the main store, but be a complement, a specialist that is allowed to drop stuff it finds irrelevant, while the big store carries everything.

Google has a problem in that Samsung is making more money by selling their phones than Google is making overall, all while much of the basis of that success is Android, provided by Google to Samsung (and others) for free. The strange part is that Google actually has a comparative advantage in producing software, so what are they going to do to ensure higher profits from their creation?

The license for Android would allow Google to stop distributing new additions for free, they have already put some popular apps under their thumb. On the other hand Samsung is working hard to replace them with their own versions to provide differentiation. Google has already published quite a lot of code, the question is whether there are enough improvements remaining, and whether Google can do them with sufficient superior quality to regain ownership and profitability for Android.

The problem is that Google’s past generosity (ignore the Java theft for a moment) has put them into a difficult middle position. The latest Android is more than good enough for webphones, those basic smartphones for cost conscious buyers who do not want much more than a web browser, Facebook and a camera. And on the high end side it has Apple to innovate against.

Their best hope is that the future will move towards the cloud phone, where they have a lot of experience.

This is the first update of iOS that has downsides to it, namely the new maps app, but it also has a few really nice new features.

Maps

This will take some time until the data is even remotely a match for what Google provides. Search works badly, it does not find most businesses that you would expect unless you know the exact name, and when it finds some options, it points you 50 km away, where Google finds a couple of options within 5 km. Until now I never realised how closely mapping is related to search, and I can only hope that Apple will improve on that quickly.

I miss the terrain view, and the coverage of satellite images still has some way to go to cover all parts of Germany. They are also of a lower quality than those from Google, often having unnatural colours or showing cloud cover. Fortunately, Google Maps works reasonably well even in Safari, so there is a fall back when Apple is letting me down again.

I like the vector display mostly, it is a clear display, but the vectors are often too straight. It would look much better if the roads were modelled as spline curves. What I really miss is any indication of built up areas, this is important for driving, to know when you have to slow down, and it just gives a much better sense of location.

Routing integration could be better. If you have Navigon on the unit, you can only use it with some extra screen tabs, as a “public transport” provider, unfortunately it cannot be set as your default instead of the built in navigation.

When I checked the turn by turn navigation, it was reasonably efficient in the data transfer department, needing 500 KByte of cellular data for a 2 hour trip over 200km. I believe it could do a better job of displaying traffic problems, and I really missed the ability to easily get updates on alternative routes, but otherwise it already works remarkably well.

Single App Mode

Single App Mode is a great addition when you want to pass the unit to someone else to play with. While active, in-app purchases are disabled. The retries when trying to evade the sand box are time limited, with a maximum of 3 minutes. This would mean that you can break out after 20 days, which sounds like a reasonable compromise.

Bluetooth 4.0

This is a great addition, as it can be used without any extra license fees, and so would enable almost all NFC scenarios given its low power nature. It is also a way for lot of accessories to drop hacks like using the audio port to use the smartphone or iPad as their controller, now that the cost to add Bluetooth has fallen below 2$. One of these chips is the nRF8001 by Nordic Semiconductor.

The hardware is on the 4S, 5, the new iPod Touch (5th gen) and the new iPad, as well as the newest Macs. That is easily enough support to start using it.

Small Stuff

My favorite little improvement is that you can now update apps without being dumped out of the update page. There are also a lot of other small refinements to make your life easier, but unfortunately the camera connection kit still does not play nice with the Fuji X100. The German keyboard now has a variant with umlauts, but it is too tight to be usable on the iPhone, and I am afraid that using it will get me into trouble with my muscle memory.

Upgrade or not

The question whether to upgrade really comes down to your reliance on Maps. I was surprised when my mother asked me whether she should be holding off of upgrading because of it, and it shows how utterly important maps are to a mobile device. Currently Apple is far off from having good enough data in many parts of Europe. Satellite images are very often not available or of a too limited quality, the point of interest database is smaller, and it seems you can only find them as long as you know their official names, not by what they offer. Fortunately you can still access Google Maps via the browser, but it is more hassle to use than the old app, and you loose the ability to place pins on the map.

When Lloyd Chambers noticed the rather peculiar way the Save As command in Mountain Lion works, it got me thinking about how saving files should really work. During normal operation you want to never notice saving. The document should be just there when you need it, with the content you expect to see. So documents should be saved automatically, and they should preferably even get a good name automatically.

Once you have your file, it will need to support a few typical use cases:

1. You modify the content, and want the latest version kept around
2. You want to compare with a previous version to review or undo some changes
3. You want a specific version of the file to stick around, typically a version that you have shared with someone
4. You want to use an existing document with similar content as the basis to create a new document

If we look at the current implementation in OS X, we see that it is well suited to only the first two requirements, but the last two are not really supported. You essentially get a cop out in the form of the Duplicate command. But what would a better implementation look like?

To deal with use case 3, we should get the following commands to support us:

• Save Named Version will save a version which you can give a name. The OS guarantees that it will never delete this version on its own.
• Export Version allows you to select a version and create a new file from it. This would basically subsume the standard export dialog by adding the native file format as an export option. The important feature here is that the exported version will have all history removed from it.
• Clean Up Versions would allow you to scrub old versions hanging around, especially the named versions. With storage prices so cheap nowadays, this would not be used very often, but it would give peace of mind.

And for the last use case, we should be able to express our intent directly as a file command:

• New from current Document will duplicate the document, remove its history, and treat it as an unnamed document from now on, maybe with the copy of name used as the default save name. The old document will stay around in its own window.
• New from Document Changes will do the same, but also restore all changes made to the original document since it was opened. This supports people who start typing before deciding that they wanted to have a new document.

This way documents would finally behave as one unit, making the cognitive task for users a lot easier. The old save as command only makes sense as long as you understand that each document has two instances, one on disk and one in memory, and that changes done in memory are only copied to disk when you explicitly save. But if you treat the memory only as a cache of the file on disk, one layer of complexity disappears, and working with files become a lot more logical. No wonder that Apple wants to get away from this, because it makes using the computer unnecessarily complicated.

But this goal requires that your documents behave consistently no matter where they are stored. The fact that versions are only supported for local files on HFS+ volumes is a usability disaster, because now versions are making life even more complicated than before. You need to learn one model for local files, and a completely different one for remote files. This is a recipe for mistakes. So unfortunately this new approach is an all or nothing proposition: Have it implemented on all supported file systems, or nowhere. As the absolute minimum implement a local versions storage for all files opened on network drives, and keep them around for a month, so that we can rely on the versions being there when we need them.

Michael Mace has written a very nice article about the problems with Windows 8. It clearly describes the problems I feel the software will face.

The main problem with Windows 8 is that Microsoft wants to leverage Windows to fight the iPad. When you read about the the design goals, you see that Microsoft sees the future as converged devices, with keyboard, touchpad and touchscreen all in one. On the other hand, Apple, which clearly moves OS X into the direction of supporting new features introduced with iOS, keeps the user interface paradigm based on using a keyboard in combination with a touchpad, and improves upon iCloud to ensure the interoperability between them.

The basic problem with the Microsoft vision is the tension over screen sizes. The larger the screen, the larger the battery needed to power it, and the heavier the entire device. The iPad already weights 662g (1.46 lbs), and feels on the heavy side. This means that the larger screens that are needed for efficiently working with classic Windows will be too heavy and even too large to create a reasonable tablet experience. The core benefit of the iPad is that you can use it on the couch, or anywhere else without a table, and that only works as long as the device is not too heavy. But for a desktop, you want the largest screen that you can fit on the table(s) you are using and still be able to carry around.

And an iPad is cheap enough that you can buy it in addition to a laptop or desktop, we are no longer in the nineties, when a reasonable computer was much more expensive, where even when you spent 5000$ on a machine you felt it could be faster for daily work, while nowadays only video editing / computer animation feel slow on a 1000$ computer.

Also mouse based computing has different constraints, it requires different trade offs for the user interface. Metro Apps will always be suboptimal when used with a keyboard, and making classic Windows Apps work with touch requires you to waste a lot of space to make the controls touchable. Take the layout for example: thanks to Fitt’s Law, you will want to put controls on all sides with a mouse, but for touch you will want them together so that you do not have to move your hand around. Or if you have a lot of different tools to present to the user: for the mouse, you will typically show all of them, densely grouped together, and rely on the high precision possible with a mouse so that the user can select what is needed. For touch, you will provide multiple panels with the information shown in a compact way, and when you click on one of these, they will expand to show touch friendly controls to manipulate.

Let us take a very telling example of the difference between touch and mouse: The humble list. On a mouse based device, lists can easily be very tightly spaced, and a tabular grid works very well. On a touch based device on the other hand, you will need 3 to 4 lines heights to pick a line. So you will want to use three / four lines per item, using the extra lines to put info below the header instead of to the right, and maybe use multiple columns of items to avoid wasting too much space. This will mean a different approach to spreadsheets than on the desktop.

So in the end I believe that the approach Apple takes, that you need a different UI for touch than for the mouse, is the right one.

(As an aside, the best way to select text on a touch screen would be to use something like the line loop in Diet Coda, and then use a tap with another finger while you still hold down your primary finger to switch over to switch over to select mode, with the main finger now extending a selection anchored on the position you were at when you did the tap)