7 ms·

"This is quite literally a new frontier, largely unexplored and full of interesting problems and unimagined edge cases. In most other realms of app design we ar

"This is quite literally a new frontier, largely unexplored and full of interesting problems and unimagined edge cases. In most other realms of app design we are spoilt with UX/UI patterns we can readily employ, but offline-first is terra incognita, there is practically nothing to go on in terms of patterns and metaphors." Alright, let's step back a minute here. We have over a quarter-century of offline-ONLY desktop applications to draw on. There are also a fair number of intermittently-online desktop applications that have been in existence for years. I realize it's not fashionable to consider these as applicable, but the only thing new here is the platform (browser). UI patterns abound - though unsurprisingly a quick google search for UI design patterns doesn't show anything except the latest web ui patterns. These desktop applications still power the everyday work of most computer users[1], to a large extent more than most transient web-based apps. Why would we start any discussion on the assumption that they're not relevant? [1] and before you tell me that you do just fine on your chromebook using only connected services: you are NOT most desktop users.

janl 13y ago
@GrinningFool totally miscommunication, sorry if we cam off wrong. We don’t mean to dismiss the offline metaphors we know from desktop apps, in fact we desperately need to transform them over to predominant app design, especially on mobile.
- GrinningFool 13y ago
  Thanks for the clarification.
npsimons 13y ago
We have over a quarter-century of offline-ONLY desktop applications to draw on. and though unsurprisingly a quick google search for UI design patterns doesn't show anything except the latest web ui patterns. . . . seem to contradict each other. Sure, offline (or at least intermittently connected) apps have been around a long time, but as you so rightly (unsurprisingly) found, that kind of thinking (patterns) has been surpassed by more trendy ideas. Part of it can be blamed on the SDK and API designers; they implicitly tell us "your app will be online all the time". Part of it (as you pointed out), is due to general ignorance of history. I think a large part of this is that large swathes of new programmers (only in it for the money?) have jumped on the apps bandwagon on phones (online by default), offline be damned. That, as the authors argue, should be fixed.
lstamour 13y ago
Generally speaking, when offline apps went online, they would "sync". This process is not straightforward, quick nor modern. Web apps don't "sync", they just "work". How can you design a native app that behaves like a web app? That's a less explored question. I'm not saying it hasn't been looked at yet, of course, and phones are some of the first to do it. Microsoft could take the lead here, with their approach of "only showing icons for connectivity when the connectivity changes" and of hiding buttons when they aren't going to work, so you can presume that anything you see on screen is going to work even when offline. Windows Phone and Windows 8 guidelines have a few more examples like this. On the other side of the fence, Apple has done similarly with their apps. iTunes Radio will continue caching the next song and part of the song after it, so even when I go down to the subway and lose signal, I still get to hear another 5 min of music. That said, the rewind and replay features of TuneIn were still superior and it'd be nicer still if iTunes radio transitioned into playing back either cached tracks or my own library instead of stopping dead. (Wouldn't it be nice if while listening, between tracks or when it stops, Siri stepped in and announced why the track can't play and suggests alternatives?) Part of this new medium is to come up with techniques of explaining that apps work offline -- people's expectations, still, are that if they visit a website, they need to be online. That alone is a huge hurdle. In addition, some of the best services, e.g. browser-based push notifications from Apple (rather than those of native Chrome) will not work without Internet since they use the same push protocols as native push notifications on iOS (iirc). That said, even on iOS, I think apps can now add notifications without internet, so that should be changing, just as apps can sign up to do background pre-caching of data. There are some HTML-only problems too: How do you version web requests from remote hosts? How about third-party JS? There are so many considerations in offline scenarios that most web developers never need consider. I really hope offline first takes off as the next "mobile first" or "responsive design". If nothing else, it will make for more robust online-only apps.
- stan_rogers 13y ago
  The paradigm is not particularly new, even if the implementation needs to be. You're essentially describing IBM (Lotus) Notes sans cruft (proprietary rich text structures, UI, etc., that predate HTML/WWW). Space- and/or time-limited replication when getting the whole data set is unnecessary, local design/code caching and so forth are solved problems, so to speak. (They've been solved at least once before, and so an be solved again.) Say what you will about the Notes client (as a developer, I had to fight it every step of the way), but the underlying ideas are still valid and, IMHO, still necessary.
chestnut-tree 13y ago
"We have over a quarter-century of offline-ONLY desktop applications to draw on" I agree. You can't even span a table cell in Google Docs. Wordperfect 5.0 could do this over 20 years ago. This is not progress. So many "cloud" or browser-based apps have limited functionality compared to their desktop equivalents. The makers of these apps tout the simplicity of these apps as a selling point. But simplicity is not necessarily the absence of features (in fact, simply removing features could be argued as the lazy way of simplifying your app). What's more, online apps give companies unprecedented opportunities to track online behaviour. This is one reason why I would never use Google's ChromeOS. Even something as simple as printing to your desktop printer requires signing into Google's cloud printing service. It's clearly in the interests of Google (and other online app companies) to sell the idea of online apps and services as the way forward. I'm certainly not convinced that it is the way forward.
205guy 13y ago
It's funny how GrinningFool seems to be associating "online" apps with cloud-based services (Google docs, dropbox, etc.) and thus equating offline with their pre-cloud iterations. I think the OP's intent applies to every app that uses data (pretty much most apps except self-contained games). Think of something like Foursquare (remember them?) that is geo-based, yet totally dependent on communicating to their server. I never used the app, but how did it handle not having a data connection? Better yet, look at the iPhone's built in Mail app. It creates an outbox for any email I try to write and send while offline (so it can handle being offline), but at the same time, it gives me a no-connection pop-up warning for almost every action I take, which is understandable, but also not very usable. Also, the old offline-only apps are NOT the same (in terms of UI and behavioer) because the new offline-aware apps have to live in both worlds. They must do work when connected and "cache" work (both up- and down-stream) when not connected--and they must do this seamlessly even when the connection can come and go without notice or predictable duration. I think it's this dual nature that the OP is talking about and I agree it is a new paradigm that most apps don't handle gracefully.
- GrinningFool 13y ago
  I don't think I was making any association between online & cloud that wasn't inferred from the article itself. I could be mistaken though. Desktop mail clients have been queueing mail for delivery since their inception (as have MTAs but that's out of scope here). A desktop mail client also has to live in both worlds - while you have a connection you expect to be able to get near-real-time notification of new messages; yet while you're offline you expect to be able to view most of your message content as well as compose and queue messages. You more-or-less expect to be unaware that you're offline. Firefox supports an offline mode where all content is served from cache (I'm not sure if Chrome does, haven't used it recently). Switching into and out of it isn't very graceful or automatic, but it is there and fairly well done. Which leads back to my point. I agree it should be done gracefully, and will concede that the kinds of data have changed. However, at heart it has been done previously, and more-or-less gracefully. In an age of always-connected phones, web apps, and a world confined to the browser, those lessons seem to have been forgotten - I just wouldn't want to see this go the route of re-learning them from first principles.

janl 13y ago

@GrinningFool totally miscommunication, sorry if we cam off wrong. We don’t mean to dismiss the offline metaphors we know from desktop apps, in fact we desperately need to transform them over to predominant app design, especially on mobile.

GrinningFool 13y ago
Thanks for the clarification.

npsimons 13y ago

We have over a quarter-century of offline-ONLY desktop applications to draw on. and though unsurprisingly a quick google search for UI design patterns doesn't show anything except the latest web ui patterns. . . . seem to contradict each other. Sure, offline (or at least intermittently connected) apps have been around a long time, but as you so rightly (unsurprisingly) found, that kind of thinking (patterns) has been surpassed by more trendy ideas. Part of it can be blamed on the SDK and API designers; they implicitly tell us "your app will be online all the time". Part of it (as you pointed out), is due to general ignorance of history. I think a large part of this is that large swathes of new programmers (only in it for the money?) have jumped on the apps bandwagon on phones (online by default), offline be damned. That, as the authors argue, should be fixed.

lstamour 13y ago

Generally speaking, when offline apps went online, they would "sync". This process is not straightforward, quick nor modern. Web apps don't "sync", they just "work". How can you design a native app that behaves like a web app? That's a less explored question. I'm not saying it hasn't been looked at yet, of course, and phones are some of the first to do it. Microsoft could take the lead here, with their approach of "only showing icons for connectivity when the connectivity changes" and of hiding buttons when they aren't going to work, so you can presume that anything you see on screen is going to work even when offline. Windows Phone and Windows 8 guidelines have a few more examples like this. On the other side of the fence, Apple has done similarly with their apps. iTunes Radio will continue caching the next song and part of the song after it, so even when I go down to the subway and lose signal, I still get to hear another 5 min of music. That said, the rewind and replay features of TuneIn were still superior and it'd be nicer still if iTunes radio transitioned into playing back either cached tracks or my own library instead of stopping dead. (Wouldn't it be nice if while listening, between tracks or when it stops, Siri stepped in and announced why the track can't play and suggests alternatives?) Part of this new medium is to come up with techniques of explaining that apps work offline -- people's expectations, still, are that if they visit a website, they need to be online. That alone is a huge hurdle. In addition, some of the best services, e.g. browser-based push notifications from Apple (rather than those of native Chrome) will not work without Internet since they use the same push protocols as native push notifications on iOS (iirc). That said, even on iOS, I think apps can now add notifications without internet, so that should be changing, just as apps can sign up to do background pre-caching of data. There are some HTML-only problems too: How do you version web requests from remote hosts? How about third-party JS? There are so many considerations in offline scenarios that most web developers never need consider. I really hope offline first takes off as the next "mobile first" or "responsive design". If nothing else, it will make for more robust online-only apps.

stan_rogers 13y ago
The paradigm is not particularly new, even if the implementation needs to be. You're essentially describing IBM (Lotus) Notes sans cruft (proprietary rich text structures, UI, etc., that predate HTML/WWW). Space- and/or time-limited replication when getting the whole data set is unnecessary, local design/code caching and so forth are solved problems, so to speak. (They've been solved at least once before, and so an be solved again.) Say what you will about the Notes client (as a developer, I had to fight it every step of the way), but the underlying ideas are still valid and, IMHO, still necessary.

chestnut-tree 13y ago

"We have over a quarter-century of offline-ONLY desktop applications to draw on" I agree. You can't even span a table cell in Google Docs. Wordperfect 5.0 could do this over 20 years ago. This is not progress. So many "cloud" or browser-based apps have limited functionality compared to their desktop equivalents. The makers of these apps tout the simplicity of these apps as a selling point. But simplicity is not necessarily the absence of features (in fact, simply removing features could be argued as the lazy way of simplifying your app). What's more, online apps give companies unprecedented opportunities to track online behaviour. This is one reason why I would never use Google's ChromeOS. Even something as simple as printing to your desktop printer requires signing into Google's cloud printing service. It's clearly in the interests of Google (and other online app companies) to sell the idea of online apps and services as the way forward. I'm certainly not convinced that it is the way forward.

205guy 13y ago

It's funny how GrinningFool seems to be associating "online" apps with cloud-based services (Google docs, dropbox, etc.) and thus equating offline with their pre-cloud iterations. I think the OP's intent applies to every app that uses data (pretty much most apps except self-contained games). Think of something like Foursquare (remember them?) that is geo-based, yet totally dependent on communicating to their server. I never used the app, but how did it handle not having a data connection? Better yet, look at the iPhone's built in Mail app. It creates an outbox for any email I try to write and send while offline (so it can handle being offline), but at the same time, it gives me a no-connection pop-up warning for almost every action I take, which is understandable, but also not very usable. Also, the old offline-only apps are NOT the same (in terms of UI and behavioer) because the new offline-aware apps have to live in both worlds. They must do work when connected and "cache" work (both up- and down-stream) when not connected--and they must do this seamlessly even when the connection can come and go without notice or predictable duration. I think it's this dual nature that the OP is talking about and I agree it is a new paradigm that most apps don't handle gracefully.

GrinningFool 13y ago
I don't think I was making any association between online & cloud that wasn't inferred from the article itself. I could be mistaken though. Desktop mail clients have been queueing mail for delivery since their inception (as have MTAs but that's out of scope here). A desktop mail client also has to live in both worlds - while you have a connection you expect to be able to get near-real-time notification of new messages; yet while you're offline you expect to be able to view most of your message content as well as compose and queue messages. You more-or-less expect to be unaware that you're offline. Firefox supports an offline mode where all content is served from cache (I'm not sure if Chrome does, haven't used it recently). Switching into and out of it isn't very graceful or automatic, but it is there and fairly well done. Which leads back to my point. I agree it should be done gracefully, and will concede that the kinds of data have changed. However, at heart it has been done previously, and more-or-less gracefully. In an age of always-connected phones, web apps, and a world confined to the browser, those lessons seem to have been forgotten - I just wouldn't want to see this go the route of re-learning them from first principles.