davidbgk
/
larlet-fr-david-cache

<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang=fr>
<!-- Has to be within the first 1024 bytes, hence before the <title>
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset=utf-8>
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
<!-- Required to make a valid HTML5 document. -->
<title>The End Of Apps As We Know Them (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/static/david/icons/favicon.ico">
<meta name="apple-mobile-web-app-title" content="David Larlet">
<meta name="application-name" content="David Larlet">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- That good ol' feed, subscribe :p. -->
<link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="http://blog.intercom.io/the-end-of-apps-as-we-know-them/">

<style>
/* http://meyerweb.com/eric/tools/css/reset/ */
html, body, div, span,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, address, big, cite, code,
del, dfn, em, img, ins,
small, strike, strong, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section { display: block; }
body { line-height: 1; }
blockquote, q { quotes: none; }
blockquote:before, blockquote:after,
q:before, q:after {
  content: '';
  content: none;
}
table {
  border-collapse: collapse;
  border-spacing: 0;
}

/* http://practicaltypography.com/equity.html */
/* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */
/* https://www.filamentgroup.com/lab/js-web-fonts.html */
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');
  font-weight: 300;
  font-style: italic;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'ConcourseT3';
  src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),
       url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}


/* http://practice.typekit.com/lesson/caring-about-opentype-features/ */
body {
  /* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */
  font-family: "EquityTextB", Palatino, serif;
  background-color: #f0f0ea;
  color: #07486c;
  font-kerning: normal;
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: subpixel-antialiased;
  text-rendering: optimizeLegibility;
  font-variant-ligatures: common-ligatures contextual;
  font-feature-settings: "kern", "liga", "clig", "calt";
}
pre, code, kbd, samp, var, tt {
  font-family: 'TriplicateT4c', monospace;
}
em {
  font-style: italic;
  color: #323a45;
}
strong {
  font-weight: bold;
  color: black;
}
nav {
  background-color: #323a45;
  color: #f0f0ea;
  display: flex;
  justify-content: space-around;
  padding: 1rem .5rem;
}
  nav:last-child {
    border-bottom: 1vh solid #2d7474;
  }
  nav a {
    color: #f0f0ea;
  }
  nav abbr {
    border-bottom: 1px dotted white;
  }

h1 {
  border-top: 1vh solid #2d7474;
  border-bottom: .2vh dotted #2d7474;
  background-color: #e3e1e1;
  color: #323a45;
  text-align: center;
  padding: 5rem 0 4rem 0;
  width: 100%;
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
}
  h1.single {
    padding-bottom: 10rem;
  }
  h1 span {
    position: absolute;
    top: 1vh;
    left: 20%;
    line-height: 0;
  }
    h1 span a {
      line-height: 1.7;
      padding: 1rem 1.2rem .6rem 1.2rem;
      border-radius: 0 0 6% 6%;
      background: #2d7474;
      font-size: 1.3rem;
      color: white;
      text-decoration: none;
    }
h2 {
  margin: 4rem 0 1rem;
  border-top: .2vh solid #2d7474;
  padding-top: 1vh;
}
h3 {
  text-align: center;
  margin: 3rem 0 .75em;
}
hr {
  height: .4rem;
  width: .4rem;
  border-radius: .4rem;
  background: #07486c;
  margin: 2.5rem auto;
}
time {
  display: bloc;
  margin-left: 0 !important;
}
ul, ol {
  margin: 2rem;
}
ul {
  list-style-type: square;
}
a {
  text-decoration-skip-ink: auto;
  text-decoration-thickness: 0.05em;
  text-underline-offset: 0.09em;
}
article {
  max-width: 50rem;
  display: flex;
  flex-direction: column;
  margin: 2rem auto;
}
  article.single {
    border-top: .2vh dotted #2d7474;
    margin: -6rem auto 1rem auto;
    background: #f0f0ea;
    padding: 2rem;
  }
  article p:last-child {
    margin-bottom: 1rem;
  }
p {
  padding: 0 .5rem;
  margin-left: 3rem;
}
  p + p,
  figure + p {
    margin-top: 2rem;
  }

blockquote {
  background-color: #e3e1e1;
  border-left: .5vw solid #2d7474;
  display: flex;
  flex-direction: column;
  align-items: center;
  padding: 1rem;
  margin: 1.5rem;
}
  blockquote cite {
    font-style: italic;
  }
  blockquote p {
    margin-left: 0;
  }

figure {
  border-top: .2vh solid #2d7474;
  background-color: #e3e1e1;
  text-align: center;
  padding: 1.5rem 0;
  margin: 1rem 0 0;
  font-size: 1.5rem;
  width: 100%;
}
  figure img {
    max-width: 250px;
    max-height: 250px;
    border: .5vw solid #323a45;
    padding: 1px;
  }
figcaption {
  padding: 1rem;
  line-height: 1.4;
}
aside {
  display: flex;
  flex-direction: column;
  background-color: #e3e1e1;
  padding: 1rem 0;
  border-bottom: .2vh solid #07486c;
}
  aside p {
    max-width: 50rem;
    margin: 0 auto;
  }

/* https://fvsch.com/code/css-locks/ */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
  font-size: 1rem;
  line-height: calc( 1.5em + 0.2 * 1rem );
}
h1 {
  font-size: 1.9rem;
  line-height: calc( 1.2em + 0.2 * 1rem );
}
h2 {
  font-size: 1.6rem;
  line-height: calc( 1.3em + 0.2 * 1rem );
}
h3 {
  font-size: 1.35rem;
  line-height: calc( 1.4em + 0.2 * 1rem );
}
@media (min-width: 20em) {
  /* The (100vw - 20rem) / (50 - 20) part
     resolves to 0-1rem, depending on the
     viewport width (between 20em and 50em). */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );
    margin-left: 0;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
}
@media (min-width: 50em) {
  /* The right part of the addition *must* be a
     rem value. In this example we *could* change
     the whole declaration to font-size:2.5rem,
     but if our baseline value was not expressed
     in rem we would have to use calc. */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * 1rem );
    line-height: 1.5em;
  }
  p, li, pre, details {
    margin-left: 3rem;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * 1rem );
    line-height: 1.2em;
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * 1rem );
    line-height: 1.3em;
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * 1rem );
    line-height: 1.4em;
  }
  figure img {
    max-width: 500px;
    max-height: 500px;
  }
}

figure.unsquared {
  margin-bottom: 1.5rem;
}
  figure.unsquared img {
    height: inherit;
  }


@media print {
  body { font-size: 100%; }
  a:after { content: " (" attr(href) ")"; }
  a, a:link, a:visited, a:after {
    text-decoration: underline;
    text-shadow: none !important;
    background-image: none !important;
    background: white;
    color: black;
  }
  abbr[title] { border-bottom: 0; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  img { page-break-inside: avoid; }
  @page { margin: 2cm .5cm; }
  h1, h2, h3 { page-break-after: avoid; }
  p3 { orphans: 3; widows: 3; }
  img {
    max-width: 250px !important;
    max-height: 250px !important;
  }
  nav, aside { display: none; }
}

ul.with_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_columns {
    column-count: 2;
  }
}
@media (min-width: 50em) {
  ul.with_columns {
    column-count: 3;
  }
}
ul.with_two_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_two_columns {
    column-count: 1;
  }
}
@media (min-width: 50em) {
  ul.with_two_columns {
    column-count: 2;
  }
}

.gallery {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-around;
}
  .gallery figure img {
    margin-left: 1rem;
    margin-right: 1rem;
  }
  .gallery figure figcaption {
    font-family: 'ConcourseT3'
  }

footer {
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
  border-top: 3px solid white;
  padding: 4rem 0;
  background-color: #07486c;
  color: white;
}
  footer > * {
    max-width: 50rem;
    margin: 0 auto;
  }
  footer a {
    color: #f1c40f;
  }
  footer .avatar {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    float: left;
    -webkit-shape-outside: circle();
    shape-outside: circle();
    margin-right: 2rem;
    padding: 2px 5px 5px 2px;
    background: white;
    border-left: 1px solid #f1c40f;
    border-top: 1px solid #f1c40f;
    border-right: 5px solid #f1c40f;
    border-bottom: 5px solid #f1c40f;
  }
</style>

<h1>
  <span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>
  The End Of Apps As We Know Them (archive)
  <time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>
</h1>
<section>
  <article>
    <h3><a href="http://blog.intercom.io/the-end-of-apps-as-we-know-them/">Source originale du contenu</a></h3>
    <p class="opening_paragraph">The experience of our primary mobile screen being a bank of app icons that lead to independent destinations is dying. And that changes what we need to design and build.</p>

<p>How we experience content via connected devices &#8211; laptops, phones, tablets, wearables &#8211; is undergoing a dramatic change. The idea of an app as an independent destination is becoming less important, and the idea of an app as a publishing tool, with related notifications that contain content and actions, is becoming more important. This will change what we design, and change our product strategy.</p>

<h2>No more screens full of app icons</h2>

<p>This is such a paradigm shift it requires plenty of explaining. Whilst it may not transpire exactly as I’m about to describe, there is no doubt what we have today &#8212; screens of apps &#8212; is going to dramatically change. Bear with me as I run through the context.</p>

<p>The idea of having a screen full of icons, representing independent apps, that need to be opened to experience them, is making less and less sense. The idea that these apps sit in the background, pushing content into a central experience, is making more and more sense. That central experience may be something that looks like a notification centre today, or something similar to Google Now, or something entirely new.</p>

<p>The primary design pattern here is cards. Critically it’s not cards as a simple interaction design pattern for an apps content, but as containers for content that can come from any app. This distinction may appear subtle at first glance, but it’s far from it. To understand it, and chart the trajectory, we need to quickly run through two things.</p>

<ol>
<li><b> Designing systems not destinations</b></li>
</ol>

<p>I covered this topic in detail in a <a href="http://blog.intercom.io/design-futures-1-creating-systems-not-products/">previous post</a>, so I’ll quickly summarise here. Most of us building software are no longer designing destinations to drive people to. That was the dominant pattern for a version of the Internet that is disappearing fast. In a world of many different screens and devices, content needs to be broken down into atomic units so that it can work agnostic of the screen size or technology platform. For example, Facebook is not a website or an app. It is an eco-system of objects (people, photos, videos, comments, businesses, brands, etc.) that are aggregated in many different ways through people’s newsfeeds, timelines and pages, and delivered to a range of devices, some of which haven’t even been invented yet. So Facebook is not a set of webpages, or screens in an app. It’s a system of objects, and relationships between them.</p>

<ol start="2">
<li><b> Recent changes to iOS and Android notifications</b></li>
</ol>

<p>Things changed with iOS 8 and Android KitKat. Notifications used to be signposts to go to other places. A notification to tell you to open an app. To open a destination.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/end-of-apps-3-non-blur.png" alt="" /></div>

<p>But that is changing fast. For a while now, you can take action directly in Android notifications. Sometimes that takes you to that action in the app itself, but sometimes you can do the action directly, meaning that you don’t need to open the app at all.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/end-of-apps-4.png" alt="" /></div>

<p>iOS is following suit here and raising the bar. Interactive notifications. No need to open the app. The notification is the full experience.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/end-of-apps-1.png" alt="" /></div>

<p>The next version of Android takes this even further, breaking notifications into independent cards. You can see that cards stack below each other.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/end-of-apps-2.png" alt="" /></div>

<p>We’ve moved pretty quickly from notifications as signposts, to <strong>containers</strong> (cards) that include <strong>content</strong>, and <strong>actions</strong> on that content.</p>

<h3>Next up: cards housing full product experiences</h3>

<p>The next iteration is obvious. Lots and lots of notification cards that enable full product experiences and independent workflows right inside the card. Comment on the Facebook post. Retweet the tweet. Buy the item on Amazon. Check in for the flight. Share the news story. Add the reminder to your to-do list. Book the restaurant. Swap the fantasy football player. Annotate the run you just finished. Pay the bill. And on and on.</p>

<h3>Towards apps as services</h3>

<p>Breaking things right down into the individual atomic unit, including the content and actions. The atomic unit separate from the container of the app itself, so that it can show up anywhere, on any device. The atomic units are then reassembled based on context. Aggregated in a centralised stream. Or pushed to you on your watch.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/Wear-Watch.png" alt="" /></div>

<p>The content may be reformatted to enable more natural user input, optimized for your situation. Des sent me a text based message, but I’m driving so my watch reads it out to me. I speak my reply to Siri/Google and Des receives it as a text based message, because he’s in work at his desk. The actions available change. All this and more is just about to happen.</p>

<p>It may be very likely that the primary interface for interacting with apps will not be the app itself. The app is primarily a publishing tool. The number one way people use your app is through this notification layer, or aggregated card stream. Not by opening the app itself.</p>

<p>In a world where notifications are full experiences in and of themselves, the screen of app icons makes less and less sense. Apps as destinations makes less and less sense. Why open the Facebook app when you can get the content as a notification and take action &#8212; like something, comment on something &#8212; right there at the notification or OS level. I really believe screens of apps won’t exist in a few years, other than buried deep in the device UI as a secondary navigation.</p>

<h2>A concept design to make this concrete</h2>

<p>This is such a fundamental shift that to highlight where it may go, I&#8217;ll start with a rough system design for how one might interact with a connected device in this world.</p>

<p>&#8211; Imagine a vertical stream of cards, individually personalised and ranked based on who and what you care about, your current context (location, availability, etc.) and your likelihood to care about things based on historical data when you were in a similar context.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/end-of-apps-6.png" alt="" /></div>

<p>&#8211; The cards can come from any source that you care about or have given permission to.</p>

<p>&#8211; This looks a lot like Google Now, but on steroids. You will have almost as many unique sources in your stream as you have apps on your phone.</p>

<p>&#8211; This also looks a lot like your notifications centre on your phone, but rather than merely signposts to open apps, these cards are notifying you, presenting you with the content to decide what to do next, and with the ability to interact with the content right there and then. So a card from Facebook has all the actions you would have for that content if you viewed it in the Facebook app. Like, comment, share, save, etc. all inline, with no need to open the Facebook app. Cards from travel apps allow you to book, cards from commerce apps allow you to buy, the list is endless.</p>

<p>This is the beginning of the end for apps as destinations. Why open the app when you don&#8217;t need to? Let’s take this a step further.</p>

<p>Imagine that you can scroll horizontally, and that shows you more content from the same source. So on a Facebook post, that is effectively your newsfeed presented horizontally rather than vertically.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/end-of-apps-7.png" alt="" /></div>

<p>This would be the same for all sources, Twitter, Instagram, WhatsApp, news apps, etc. And of course on all devices.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/end-of-apps-8.png" alt="" /></div>

<p>OK now let’s go a step further again.</p>

<p>Imagine that a parent card can support a child card, so for example a Facebook card can support (embed) a card from the BBC. Indeed something similar already exists with Twitter.</p>

<div class="post_image_wrapper"><img src="http://43y3qy2bx0ks2g9x564339n2.wpengine.netdna-cdn.com/wp-content/uploads/2014/10/Parent-Child.png" alt="" /></div>

<p>This is also a little similar to the recently launched Apple Extensions, and is already happening in app development in China with Baidu and WeChat, where smaller apps are being bundled within bigger apps, only surfacing when some interaction in the UI invokes the smaller app. For example, in Baidu Maps you can find a hotel, check room availability, and make a booking, all inside the app.</p>

<p>But again the apparent subtlety masks something much more profound. Embedded cards (child cards) within cards (parent cards) also mean <em>you don&#8217;t need to install the app</em> to experience the content from the child card. You just need the parent card app on your device. Again, this is already happening, Twitter cards currently support Stripe payments inside the card. You don’t need the New York Times app to see their content on Twitter. But imagine this pattern was widespread. Suddenly app developers have a powerful discovery channel. And some businesses may be comfortable always appearing as a child card, without ever having an app at all.</p>

<p>One final step further. What if the cards came from other <a href="http://google.github.io/physical-web/"><em>things</em></a>? Like vending machines that you walk up to and pay through the card? Hotels you walk into and order your breakfast or pay for the wifi?</p>

<p>The ramifications for websites might also be huge. If a publishing company, for example the New York Times, can push content to cards, and those cards can be seen in many different third party places (with revenue sharing agreements) why bother having a website at all? It&#8217;s just a huge overhead.</p>

<h3>We will still open apps. Sometimes</h3>

<p>In this world, it feels dumb to open apps just to see what lies behind the red counter, or to have to switch between apps. Opening apps is still necessary and great for many contexts, especially composition of new content and dedicated deep workflows, and maybe changing preferences. But not for seeing what&#8217;s new and interesting. A bank of app icons as a dominant design pattern feels old and inefficient now, and I think it&#8217;ll disappear within a couple of years, correctly relegated behind a “show me my apps” action.</p>

<h3>The system will learn, creating new competitors</h3>

<p>As people interact or don’t interact with cards presented to them, the system will learn when to show more or less from a specific source (app). As content from different apps will be presented side by side, this changes who you might think you are competing with. Competition is between products that do the same job, not products that are in the same category.  This is already the case today; when faced with multiple notifications on a phone screen, they all compete with each other for your attention.</p>

<p>Here at Intercom, we’re big proponents of the Jobs To Be Done (JTBD) framework, which asks what Job people need to get done that your product fulfills. If you focus purely on the job, and not the industry, you realise airlines selling business class seats are competing with Skype for customers, as they address the same job: the need to have clear communication with colleagues.</p>

<p>Similarly, apps will realise they are competing on Jobs they may not have realised their product addresses. Twitter for example, may be competing much more with apps addressing the Job of ‘entertain me while I have a short amount of free time’ e.g. Games and News apps, than with other social products.</p>

<p>This intense competition means businesses will have to spend time designing great notifications/cards, because they will potentially be competing with cards from Facebook, or Amazon, or Google. The days of sending lots and lots of notifications to bring people back to an app are going away, with a much better focus on designing notifications that people engage with there and then, independent of opening the app.</p>

<h3>Three critical questions</h3>

<p>There are many signs pointing towards a near future that looks something like this. But many questions remain &#8212; these are three that I have no answers for:</p>

<ol>
<li>Will this happen at the app, notification, or OS level?</li>
</ol>

<p>One of the biggest challenges will be whether these experiences will occur:</p>

<ul>
<li>at an app level (like an evolution of Google Now),</li>
<li>at a notification level (an evolution of the Android or iOS notification centre),</li>
<li>or at the root OS level (a redesigned iOS for example that removes the sea of app icons).</li>
</ul>

<ol start="2">
<li>Will this be one consolidated stream, or multiple streams?</li>
</ol>

<p>Maybe we will have a friends stream, a news stream, a work stream.</p>

<ol start="3">
<li>Will this be owned at a company level?</li>
</ol>

<p>Maybe there will be a Google version, an Apple version, etc. Or more open systems that are interoperable across platforms (like the web itself), the first of which (like <a href="http://www.trywildcard.com/">Wildcard</a> and <a href="https://citia.com/content/title/citia">Citia</a>) are being built now, could come to dominate.</p>

<h2>Towards better businesses and products</h2>

<p>This is just a sketch but at a conceptual level I think it&#8217;s largely where we are headed. Large parts of this are built already; things like Google Now, Android notifications, iOS8 interactive notifications, iOS8 extensions, Twitter cards. Emerging platforms like Android Wear and Apple Watch are confirming these trends towards cards that work as notifications, content and actions.</p>

<p>There are also a multitude of user benefits:</p>

<p>This new paradigm matches much more closely with how real life works. We don&#8217;t live our lives in silos, like the app silos that exist today. People start to forget about “apps” and just think about businesses and products and services. This is a great thing, the container for content should be invisible to users.</p>

<p>This new paradigm also solves a critical problem around volume of incoming content. Navigating to lots of apps is so inefficient. A new problem emerging is an overwhelming volume of notifications. Things will need to be ranked, which will make them more manageable. It&#8217;s also a better experience, apps maximising their usefulness in a quick lightweight fashion rather than dominating your attention in a slow heavyweight app-oriented experience.</p>

<p>The constraint of an individual card also makes you think about the most important thing you could show, and only the most important actions relating to that. That constraint is very powerful.</p>

<p>For businesses, it also starts to solve the app discoverability problem. Rather than relying on App Store promotion, advertising, or new deep in app linking to get discovered, an apps content can appear as a card in our stream, particularly when embedded in a parent card. Indeed there may not be a child app, the content and actions in that child card may come from the web.</p>

<p>This paradigm shift also starts to ask questions of the bundle or unbundle dilemma (btw both are happening now, it&#8217;s not just unbundling). Maybe in this world you can have your cake (unbundled simple focused one task experiences) and eat it too (bundled into a coherent individual stream). A deliberately designed eco system of cards where cards are simple, but can carry information and context from other cards you build.</p>

<h2>5 key take aways</h2>

<ol>
<li>These patterns reinforce two things we wrote about here on Inside Intercom early in their development. That <a href="http://blog.intercom.io/why-cards-are-the-future-of-the-web/">cards are the future of the web</a>, and designers need to design <a href="http://blog.intercom.io/design-futures-1-creating-systems-not-products/">systems not destinations</a>. Cards are happening. Systems are happening. Get fully up to speed on both of these things.</li>
<li>Responsive design is a nice thing, but we’re heading way beyond that. We’re talking about designing content that may appear on an incomprehensible number of devices and in an incomprehensible number of situations. This will need new design principles, new ways of thinking about researching context. Push forward with this yourself, don’t wait for it to happen.</li>
<li>Designing the notifications, and the actions within them, will become an increasingly important part of product design. We will need to spend as much of our time on this aspect of the experience, as on the experiences within the app. Change how you think and work now, rather than when it is too late. Sketch systems, not screens.</li>
<li>Think about who you might integrate with. Integrations as part of a product strategy are increasing, witness the explosion in available APIs, Webhooks and the emergence of services like Zapier and IFTTT. Integrations make things possible that you could never do alone. They give you access to new audiences. Make integrations part of your business plan, product strategy, and product design.</li>
<li>I carry around both an iPhone and an Android phone. I often also have my iPad Mini. I wear a Nike Fuelband. I’ve tried Google Glass whenever I can (in private ;-)). When I can I’ll buy an Apple Watch. We all need to dive headfirst into this, eyes open, trying to see what works and fails, trial and error.</li>
</ol>

<p>If you made it this far, thanks for reading. Whilst the trajectories seem clear, much is unknown, we’ll all figure this out together. So please let us know your feedback, thoughts, ideas below, and we’ll do our best to respond and keep the conversation moving forward. </p>

<p><strong>Update:</strong> Read our follow up piece: <a href="http://blog.intercom.io/its-not-the-end-of-apps/">It&#8217;s not the end of apps</a>. </p>
  </article>
</section>


<nav id="jumpto">
  <p>
    <a href="/david/blog/">Accueil du blog</a> |
    <a href="http://blog.intercom.io/the-end-of-apps-as-we-know-them/">Source originale</a> |
    <a href="/david/stream/2019/">Accueil du flux</a>
  </p>
</nav>

<footer>
  <div>
    <img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">
    <p>
      Bonjour/Hi!
      Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>
      Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).
    </p>
    <p>
      Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.
    </p>
    
    <p>
      Voici quelques articles choisis :
      <a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,
      <a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,
      <a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,
      <a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,
      <a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,
      <a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,
      <a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,
      <a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,
      <a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,
      <a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,
      <a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,
      <a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,
      <a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,
      <a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,
      <a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,
      et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>
    </p>
    <p>
      On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.
    </p>
    <p>
      Je ne traque pas ta navigation mais mon
      <abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>
      conserve des logs d’accès.
    </p>
  </div>
</footer>
<script type="text/javascript">
  ;(_ => {
    const jumper = document.getElementById('jumper')
    jumper.addEventListener('click', e => {
      e.preventDefault()
      const anchor = e.target.getAttribute('href')
      const targetEl = document.getElementById(anchor.substring(1))
      targetEl.scrollIntoView({behavior: 'smooth'})
    })
  })()
</script>