- iCloud’s real purpose is to kill Windows – "What this requires from Apple is a bold move that Microsoft would never make: Jobs is going to sacrifice the Macintosh in order to kill Windows. He isn’t beating Windows, he’s making Windows inconsequential."
- Microsoft joins pre-emptive patent protection program – Software patents are not really popular, even with companies that (in theory) should benefit from them…
Tag Archives: Software
My delicious.com bookmarks for March 26th through March 31st
- ‘Useless’ Is A Loaded Word – "In almost any life situation where you need to get something out of another person, being a dick is never the right method to go about it. Using loaded words like ‘useless’ or ‘worthless’ is being a dick. We will listen to your feedback and thank you for it, but unless it is some urgent issue that will affect every user, it’s most likely getting shoved to the bottom of the pile in favor of doing things to make the friendly customers happy."
- Don’t blame inflation for all the price rises – Summary: food and gadgets are cheaper, entertainment is considerably more expensive.
- We should stop running away from radiation – "A sea-change is needed in our attitude to radiation, starting with education and public information."
Why you need a crash reporter
Most developers of iOS applications have a love-hate relationship with the main interface with Apple.
No, let me re-phrase that.
Most developers of iOS applications hate iTunes Connect, the main impediment to a good relationship with Apple.
To be fair it has improved since it opened in mid-2008. One of those improvements has been the inclusion of crash reports. A crash report, in case you’re not a developer, is something that iOS devices such as iPhones and iPads write out when an application crashes. It includes all kinds of useful information, including some, but not all, of the internal state of the application in question. It’s very, very useful for diagnosing problems.
However, what has become clear is that not all of the crash reports make it into iTunes Connect. There are two, maybe three, levels of screening going on. First, the user has to sync their phone with iTunes. I do this mainly to update my podcasts but otherwise I’d do it fairly infrequently. Second, the user also needs to allow the crash reports to be uploaded. I suspect most users do but, you never can tell. Third, Apple clearly does… something with the reports when it gets them. There’s clearly some degree of filtering going on but quite what is anyones guess.
The practical upshot of all this is that you’re quite likely to hear about crashes before you see them. I’ve seen reviews in iTunes complain about crashes. I’ve received tweets and support emails. And all before a single report appears in iTunes Connect.
It’s the reviews in iTunes that bug me the most, as I have no way to ask for further information.
Until now.
The most recent version of Yummy, Yummy Browser and www.cut all included crash reporting code. That is, should the app crash, the next time it’s launched it will say as much as offer to upload the report to a web server.
As I type this I see around a hundred crash reports on my web-server and zero in iTunes Connect. Luckily, I’ve seen no bad reviews in iTunes and, surprisingly, I’ve had no support emails or queries on Twitter.
Without the crash reporter I would have had no idea there were these serious bugs — I’d never seen them! I’m always surprised about crashing bugs as I consider myself to be the main user and so likely to come across these problems first.
Using the reports I can easily see that 90% of the crashes were coming from two bugs. Interesting but slightly less importantly, I can also see that jailbroken phones seem to have more problems than others. I see that the vast majority of my users are on 4.x, with 4.2.1, by far, being the most common. (None of the bugs are OS specific so these numbers should be pretty representative.)
The other thing about having the details on a web-server is that I was able to flag them. When a crash with a known fix is submitted, the apps will now tell the user that this is the case.
I never thought I’d say that the lack of support email is a bad thing, yet there was one bug that took me a long time to track down. I could see where exactly in the code it was crashing but I could see no way that it could actually happen. In the end I stumbled across it quite by chance, but being able to talk to a user who was experiencing the problem would, in this case, have been very useful.
No software is perfect. But at least now I can see problems almost as soon as they happen and provide direct and timely feedback. This is such a huge plus that it shouldn’t be underestimated.
My delicious.com bookmarks for March 9th through March 12th
- Twitter tells third-party devs to stop making Twitter client apps – "More significantly, it demonstrates the vulnerability of building a business on top of a Web platform that is controlled by a single vendor." This is exactly the lesson I found with my Delicious.com client.
- Illinois scrubs death penalty – Another step in the right direction.
- NYT and "torture": Searching for a justification – Apparently the definition of torture depends very much on who is doing it.
All New!
This week I’ve released updates to all three of my iPhone and iPad apps.
Yummy and Yummy Browser, my Delicious.com client, see the release of a big update: version 2.6.0. It includes a completely new bookmark viewing and editing screen, a new bookmark list view, updates to help syncing reliability and lots of smaller tweaks and updates. It’s the biggest gap between any two major releases but I think is a good one.
The www.cut update is much smaller, but includes the new Facebook API (looks the same!) and some minor aesthetic tweaks.
Hidden, and not mentioned in the release notes for any of the apps, is a crash reporter. Apple do push crash logs into their developer interface, but they do seem to skip some and it only ever happens when users sync their phones to iTunes — something that people seem to be doing less and less. I’ve seen reviews and support mails from people mentioning crashes but not seen the crash reports — which makes it really difficult to diagnose a problem. Hopefully you’ll never see it, but now they’ll prompt you to send the log directly to me after a crash.
However, even with that it’s still worth pinging me a support email if you see something amiss. Firstly, if it doesn’t crash I still won’t see it. And, secondly, the crash reports come without any context. Seeing which line of code is causing a problem is very useful but without knowing how you get there it can be very difficult to correctly diagnose and fix a problem.
Your most important customers
Seth Godin has had a couple of posts recently about how to treat your best customers. One of the thing that he observes is that the way you define “best” is not necessarily the most obvious. Is a customer that pays full price always better than one that recommends your service to five of their friends?
In defining the best customers, my mind wandered to the opposite extreme, the worst customers. This reminds me of something that happened a few years ago. It’s only fair to note that I heard this “through the grape-vine.” It could be completely true or mostly made up, but where-ever it falls I think it’s an interesting anecdote.
As a reaction to, potentially, being taken for granted, customers often remind suppliers how important they are and how much money they allow the supplier to make. Undoubtedly this is a standard negotiation tactic. But where it goes wrong is where the clients self-image doesn’t match reality.
This anecdote starts with a client demanding extra resources, more commercial concessions and some impossible deadlines. Their argument: we’re you’re most important customer. We, therefore, get what we want.
Discussions had not resulted in any change in their stance. This is what we want (a lot). This is how much we will pay (not much, or at least enough to offset the pain).
The anecdote ends with a meeting. In the meeting are senior figures from both organisations. The supplier is presenting and the Powerpoint effectively has a single slide. The slide shows a simple bar chart. The bars are ordered with the largest on the left, the smallest on the right. The axis are unlabelled.
After pleasantries, the presentation starts with a statement followed by a simple question.
“This chart represents our top ten customers by revenue for the last year. Which bar are you?”
The client quickly points to the bar on the far left, the largest.
“I can’t name them, but that bar represents around £x.”
The figure was left to hang in the air. It was nearly double what this client had spent in the last year and they knew it.
The relationship had deteriorated to the point where the client was asked to make two more guesses before it was revealed that they were, in fact, the second bar from the right. It was still, I should add, a reasonable chunk of change but it quickly became clear that their “most important customer” argument would need some refining.
Anyone who has worked with difficult clients will probably be smiling at this, though of course the fact that it got to the point where this strategy was even thinkable shows a failure for both parties. While it worked, for a short time, this is a strategy that you’d only try if walking away was a reasonable option.
I guess what I’m saying is that relationships work both ways, and the best ones are made out of mutual respect. Not everyone is out to screw you. You might think that taking your supplier or client for a ride makes them your best customer or your best supplier but in the end it will likely come back to haunt you.