offlinefirst / research

Links, feedback, comments, resources, anything pertaining to offline first research.
Apache License 2.0
369 stars 16 forks source link

Offline first is an opinionated business model #14

Open electricgecko opened 10 years ago

electricgecko commented 10 years ago

Some extended thoughts stemming from my twitter convesation with @pgte, @lmjabreu and @gr2m, originating here: https://twitter.com/electricgecko/status/469527201558589440

Here's what I think:

This leads to:

janl commented 10 years ago

I love this discussion!

In the larger discussion about centralised vs decentralised systems, the centralised systems have an upper hand in commerce, as it is not only easier, but doable than in distributed systems. That is not to say, that distributed systems can’t have a commercial angle, but there isn’t one that is a mainstream success, yet (bitcoin is not there).

One conclusion for people who have a commercial interest in technology then must be is to be successful today they need to use or build a centralised system. In addition, some proponents of decentralised systems are decidedly against any commercialisation of their technology space.

I think both opinions are shortsighted, but I appreciate that today’s businesspeople take a pragmatic approach (I know I do). I also believe that, given enough people thinking about this and trying things out, we can come up with a few business models that work well in decentralised systems. Much like I believe that there can be a business model other than advertising on today’s web, just not enough people have spent enough time thinking and trying things out, or even funding this.

This isn’t to discourage all the attempts we have seen so far, or the ongoing experiments. To the contrary, we net A LOT MORE of the Bitcoins, Gittips and Flattr”s of this world, but we need to design them from mainstream end-user experiences backwards.

As a corollary, while I agree that Offline First taken into the extreme defies current business models (and maybe then, on purpose), that the UX-aspect of this is not necessarily a hindrance in making money from a service.

I agree though, with your observation, that we don’t only pay with our data, but also with every single interaction with our data and that capturing that in an Offline First context is harder than in an always connected scenario.

In a way though, I’m happy about this, because I think Offline First is a non-negotiable fact and that better experiences will have people move from more centralised systems, and thus expose them to sane data-collecting- and business practices. That said, you could build fully creepy Offline First systems, too.

So yeah, before this turns into a ramble: we need more experimentation with business models, especially in conjunction with decentralised systems :)

And more voices, please chime in!

electricgecko commented 10 years ago

Jan, i fully agree on this. And it's by no means only true for web services or technology in general – high quality coffee that takes longer to prepare is a harder sell than cheap coffee from ready-made machines. Quality is a secondary concern for many people.

The post important takeaway from your reply is: we should be thinking about economic models as long and hard as we do about technical ones. For many of us programmers, designers, people with social sciences backgrounds, the first is the harder one to crack.

janl commented 10 years ago

@electricgecko yes, this!

My comment about better experiences was more aimed at convenience, not quality. Instagram beat Facebook because convenience. That must be our road, too, except that we won’t sell to FB later :)

ghost commented 10 years ago

I'm a bit late, but here goes:

A lot of good stuff has been said already and I agree we need compatible business models. Also: this is offline-first, not offline-only right?

What I want to add is an extra focus on UX and share another view on why Siri doesn't work offline.

Essentially: that app has no way to manage expectations when working in offline mode as it has a very minimal UI and the majority of the input is done by voice.

It has no way to inform the person it can tell the time and upcoming events, but not upcoming movies, convert units or lookup definitions.

They might be trying to protect the perceived quality of the product (Siri) and therefore only allow it to function when there's an internet connection. It already has to deal with voice recognition so they might've chosen to either have it work or not instead of introducing more possibility for error—we know network isn't binary.

Siri is a very specific example, and for the majority of the apps we can indeed manage expectations and allow the core functionality to work. I just wanted to highlight a scenario where because of UX and perhaps brand you might not want to attempt to gracefully degrade the product.

Now there's something else it might be interesting to look at. I chimed in on games that can only work when there's a connection. Reasoning there seems to ensure data hasn't been tampered with and their revenue model (sometimes dubious) isn't threatened.

An offline-first game would still require a connection to do IAPs but that's not the important thing here, what's important is that this is another instance of data you own but don't necessarily have complete control.

Another example would be Banking data. You can have access to it, but only the right entities are entitled to change it. Medical, insurance, contractual and other types of data have the same conditions. (I might be rambling and this is something solved through a security model similar to the one implemented by bitcoin)

michielbdejong commented 10 years ago

I see the point of the OP and find it very insightful. But rather than saying offline-first is a competitive disadvantage when pursuing monetization, I would prefer to view monetization as a competitive advantage when pursuing offline-first. :)

As a positive example, the spotify app on iOS needs you to connect to the public internet only once every 30 days. The app will stop working as soon as it finds out that your subscription has expired, or when 30 days have past without a call to the server. That way, you can only use it for another 30 days max after your subscription expires, and only if you intentionally keep your device offline during these 30 days. I doubt a lot of people go through that effort, so for the subscription check it seems like a fair solution.

I also see the point by @lmjabreu about graceful degradation, but I think it should be easy enough to explain to the user when an action is taking longer to complete because of connectivity, and so the brand stays clean. In fact, if you use asynchronous synchronization, then it's possible to make your app more snappy and reactive than in a traditional ajax-based design, regardless of round-trip times

electricgecko commented 10 years ago

I very much agree with both of you concerning the point of always having an instance of your data (~ asynchronous synchronization). it is something I overlooked in my original post: there may be less of a technical constraint to offline-first applications than i thought. then again: regular sync seems to be really hard to begin with.

as @janl stressed: offline first leads to higher quality apps. they might be a tougher sell. so: who appreciates quality apps and are there enough of us to compete?

janl commented 10 years ago

I don’t think Offline First should be a selling factor for mainstream apps. It is an implementation detail, that ideally just works. The key to get Offline First technology to people is build more convenient user experiences (IMHO :)