Data Management

Old-Fashioned

I've seen three people this week get locked out of their gmail accounts "to keep [their] systems healthy" or for "unusual activity". Google have been doing a good job recently of tackling accounts used for spam, but all of these cases were just regular people locked out for no reason, for hours or days. In the last week Google announced Google Reader would be no more after June. Like they closed down Wave. And Picnik And Buzz. And they're completely within their right to do so. Google are an advertising company, and public company, and their goal is to make money. By selling ads. In their own words,

"We generate revenue primarily by delivering relevant, cost-effective online advertising."

They've come up with some quite amazing ideas, products and services for an ad company, but I think it's quite important to remember that. Especially if you've come to rely on their services.

I don't imagine that Google will close Gmail down any time soon. Why would they: they're constantly serving you focussed ads while you use it, and that makes them money. When there is a problem with the service though, what do you do? And what do you do if you've come to rely on something, like Reader, goes away? You can't get a refund if you never paid.

Call me old-fashioned, but if you've paid for a service, like the olden days, you're in a better position. Of course, your paid-for service could also close or be disrupted. In these cases though, as a customer, you have rights that have been enshrined in law (at least they have in this country). By paying you enter into a contract, and therefore you get to demand certain level of service and have a channel open for if or when you need it.

And then there's the ads. Call me old-fashioned, again, but I think that advertising has become one of the worst things about modern life, and targeted advertising has only made it worse.

The internet, being online, digital life: whatever you call it, it's here to stay. And for many of us it is no longer a separate part of of our lives, it's just another aspect. Before the internet, we didn't get, or expect, all our services for free, nor did we tolerate constant targeted advertising, and having our personal communications trawled through by international companies. Why now? Isn't it time we made the internet grow up? We don't have to throw it out to get back to old-fashioned customer service.

 

Update:

I've been informed (by @bigpumpkin, thanks!) that the Gmail you get with Apps For Business is ad-free. I should have realised this since we actually use it at work (though I rarely use the web interface). This is of course the solution I was suggesting: you pay for the service instead of having it ad-supported. How about a personal-tier version of this then, Google?

Paying for Social Networks

This week I was introduced to – and in turn introduced some others to – Branch. In case you're wondering what it is (I did, my first comment was "what is it?"), Branch is a new conversational tool, i.e., somewhere to hold conversations easily, in public or in private, with a branching model borrowed in spirit from Git (the revision and source control system). It's not Just Another Social Network, like one of my friends feared ("who has time to check another social network?"), but another comment indicated that it does have some things in common with social networks: "how is it going to be paid for?". This question lead to a discussion about how, and if, we should pay for social networks, that took place largely on Branch. Here, I've summarised what I said and what I learned. I realise this may go against the point of Branch in some people's minds, but for me this is exactly what it's great for: a place to hold a discussion where ideas can bubble and formulate.

I began the conversation with three ways I'd be happy to pay for a social network: 1) Pay for a good native client(s) (and leave the web version free) 2) Pay to have no ads (and allow others to use for free with ad/sponsored stuff) 3) Pay to have read/write access (allow others to read-only for free).

The main issue with the first of these was sustainability: once everyone's bought the client, how do you continue to fund the service? I'd be interested to know how Instapaper's model of an optional subscription charge works for this: I suspect that for a niche app with a cult following this could work, but it probably isn't a model most companies could follow.

Two main points arose from number two: firstly, if you're opting out of ads, are you also opting out of being mined for advertising data? Secondly, current print and broadcast media charge and show you ads anyway, and have been doing so for years.

The opting-out of being mined point is interesting: I know that some people would want to be able to opt out of this for privacy reasons (although I don't really see how you privacy is being challenged: perhaps for 'moral' reasons is a better way of putting it). Personally, though, I don't think I care if my data is mined, so long as I don't see the results, i.e. ads or promoted stuff in my news or social feeds. If a company wants to work out that in general people who talk about smartphones also talk about coffee, and so start to make cool phone-coffee holders, or billboards showing phones with coffee, I'm not sure I really care. As long as I can pay a small fee and not see an advert for CoffeePhone in my inbox, I'd be happy.

The second point about paid-for services also having ads: I'm not so sure. It's true that newspapers charge and also carry advertisements, it's also common knowledge that the cover price of a newspaper doesn't cover it's cost: the advertising does, so I'm not sure they are really doing both. HBO have proven there is a market for a premium price point with no sponsorship. One issue here though is that there is nothing stopping a service from starting with some pricing tier for 'no ads', and this then morphing into 'some ads', and a new tier of pricing being introduced for 'no ads' again.

The final option – pay for read/write access but allow for reading – is I believe what App.net do right now. When I first suggested this idea, I didn't know that they allowed this, and this unfortunately negates my idea. I haven't read a single thing on App.net since realising I could, and so it's hardly sucking me in to their world. And as someone else noted, this was the model Friends Reunited used. ("Nuff said.")

We shouldn't completely discount the model though, App.net got 10,000 backers before launching (and has already grown to around 17,500 now that they have launched) so some people clearly are happy to pay.

Which brings us back to the original proposition: should we be paying for social networks at all? I think that now we have them, we're going to be using these sorts of services – social networks and conversational tools – in one form or another, for the foreseeable future. But wouldn't it be a shame if we are constantly moving from one to the next like we are now, trying to stay ahead of the latest companies evil profit-making ways? Wouldn't we be better instead to agree on the protocols, then pay our personally chosen provider for a decent service? Like we do for landlines, and broadband and electricity. The U.S. has been plagued for years by non-standard services, and here in the U.K. for the most part we've been spared that (although that has been because of nationalisation). I don't want to live in that frontier world where the train gauges don't match up and I can't connect across to another phone because it's on another network. And I don't want to have to keep jumping from service to service riding the free-wave: I've got better things to do with my time (no, really!). We're getting to the age where social networks are growing up, and maybe our attitude to paying for things needs to grow up with them.

 

Thanks to Steve Pettifer (@srp), James Lewis (@jameslewis), Tim Marshall (@pixelcellar), Simon Dell (@simon_dell) and Claire Miller (@RedDread) for participating in the discussions this post was based on.

Update:

Here's a link to the original branch!

Making UIManagedDocument a little safer

On a recent iOS project, we had an issue with relationships between managed objects disappearing at the moment the document saved itself. The problem, it turned out, was that we were holding onto an object after immediately after creating it, and then later on setting up relationships between it and some other new objects. The ID of the object changed at the moment the document saved, and so the relationship no longer held. I found the crux of the issue by way of an excellent suggestion from Steve Tibbett's blog, which gives some great tips on troubleshooting UIManagedDocument's autosaving. The solution we came up with was to call:

+ (BOOL)obtainPermanentIDsForObjects:(NSArray *)objects error:(NSError **)error]

on the managed object context after creating each object, to ensure that its ID didn't change later (when saved). I first solved this with a subclass of NSEntityDescription with the following overload:

Solution A

I have, however, just revisited this issue, and I think that a category is a little tidier and safer. Rather than having to remember to always us theNSEntityDescription subclass, you can add the category to your pre-compiled header, and then you always have the new methods available (and the old one, in case there are times you don't want the extra complexity of the permanent ID version).

Solution B