Starting a new PWA directory

A few of us in Google's Developer Relations group are building a little demo: pwa-directory.appspot.com It's open source and code named Gulliver because it's a PWA directory in the spirit of Yahoo or DMOZ.

That means it's not a curated gallery. Instead we recommend that people who just want to see a set of exemplary PWAs should go to the pwa.rocks PWA directory.

If there's already another PWA directory why are we doing this and what do we hope to achieve?

Our primary goal is to learn in the open and share those lessons. Some of the things we hope to learn include:

• what makes people use a PWA offline?
• what constitutes a meaningful offline experience?
• what percentage of our userbase actually uses it offline?
• which PWA technologies help with acquisition, engagement, retention and re-engagement of users?
• how do we build a good cross-platform and cross-browser experience?
• what signals in analytics and Search Console indicate that we are on the right path?
• what are the things we believe or assume that are wrong?

We hope to get 1000 30DAU of this content-centric (lots of pages with URLs) PWA over the next few months. That level of regular usage should start to surface some of the challenges that big web apps face.

However this isn't a big web app so our stack is relatively simple.

• Vanilla.js
• Node.js
• Express.js
• Handlebars
• Google App Engine Node.js Flexible Environment
• Service Worker Precache
• Service Worker Toolbox
• Google Cloud Datastore for general data
• Google Cloud Storage for images only
• Google sign-in as an anti-spam hurdle for those submitting new sites.

The one clever technical feature is that we use Lighthouse As A Service. That means that every time someone submits a manifest (all we require is that the site provide a web manifest over HTTPS) we run Lighthouse inside a headless Chromium instance to collect metrics about the quality of the prospective PWA. If you’re already a Lighthouse user then you may spot that our scores sometimes differ from those you see in Lighthouse. It’s an open issue and we’re working on it.

Lighthouse is a big part of this web app’s value so it's going to be the subject of the first in a series of articles sharing the lessons we are learning in building Gulliver. Until then you can get in touch with us via Github if you have questions or feature requests.

Embeds, content and context

As a publisher you have 2 choices. You can either bring the people to your content or you can find ways for your content to flow towards the people. Historically that has meant using syndication technologies like RSS but in these days of #PeakRSS that's no longer sufficient. The audience are no longer just sitting in front of their aggregators. They're sitting in front of activity streams watching reshares and hitting reload on their favourite websites every morning.

To maximise the reach of your content you have to reduce the accidental friction (see Brooks on the difference between essential and accidental properties) involved in sharing to those activity streams. That means making it easy to share (hence the sharing buttons all over the web), making it clear why they should share (hence the various experiments encouraging you to share or tweet specific quotes from an article) and finally making the shareable unit something that can travel easily around the web.

This is where embeds come in. An embed is a card that contains a chunk of a site's functionality that can be ripped out of that site and reused elsewhere.

http://parochialaesthetics.tumblr.com/post/148169494570/eliel-saarinen-always-design-things-by-context

This can range from music players (like Soundcloud) to video players (like YouTube) to quotes (like Twitter) to whole discussion threads (like Google+). What distinguishes them from glorified screenshots or Xanadu's transclusions is their interactivity. Visitors to your site can interact with this foreign content without abandoning your site.

But isn't this what links are supposed to do? Unfortunately inline links have various problems:

• they take the user away from your site
• they break silently
• the content at the destination has to be consumed without the context provided by your site
• the destination can't provide guarantees about the experience your audience will receive and thus you can't set reliably expectations for anyone who clicks on the link

Embeds don't have these problems. They:

• keep the user on your site
• break in ways that are immediately visible
• are consumed in the context provided by your site
• can be constrained to a tiny card with a predictable UX within your site 

Embeds also represent a chance for publishers to change social media from something where your campaigns/integrations send traffic to someone else's site to something that delivers measurable value (traffic and revenue) to you. The most valuable embeds:

• convert your social efforts into traffic on your site 
• help you keep people engaged with your site
• help you increase the reach of your content
• help you use other people's content to enrich your site

Ultimately publishers will realise that embeds are just the first generation of portable content unit and they have their own limits. There will be other generations and they can offer different trade-offs.

Art, AI and Google I/O 2016

What if there are interesting things waiting to be discovered where artificial intelligence meets art?

At Google I/O 2016 Ramzi Rizk told me there's a field called Computational Aesthetics. It is so nascent that it doesn't even have a Wikipedia page. Computational Aesthetics is where computers can actually tell us if a picture is pretty or not. This is different from systems like Flickr's Interestingness because the system infers beauty from the image itself rather than from the social signals generated by people's interactions with the image. In fact there's already been research showing that social signals lead communities like Flickr to overlook hidden gems. This research raises the tantalising possibility that there may be large numbers of overlooked masterpieces hiding in the historical corpus of art.

I find this intersection of art and machine learning interesting because at scale it leads to the discovery of new tools and new perspectives on something that we consider to be uniquely human. For example the spatial visualisation used in the "Machine learning & art" talk at I/O lead me to t-SNE as a mechanism for building two-dimensional maps of high-dimensional spaces.

This raises the possibility of building pirate maps of information spaces or hypertexts and connecting that to Vannevar Bush's ideas about stigmergy in the Memex. Imagine being able to create and share your own trail through the space of all art? Or being able to reinvent the idea of the traditional slideshow of the family's holiday photos.

Today apps like Prisma merely help us make alternative versions of existing photos. At the same time apps like The Roll and Google Photos help us identify our best photos. In the future they might help photographers to create photos from scratch and tell new kinds of hypertextual stories.

Playing with #prisma (and a little bit of Clarendon) on this #latergram from #io16

A photo posted by Ade Oshineye (@ade_oshineye) on Jul 17, 2016 at 3:47pm PDT

Cargo cults and progressive web app stores

People are seeing that native app platforms have some feature and are then asking for the exact same feature for the web. Instead they should be asking about the job to be done and the benefits users or developers see from a given feature. For example app stores :

• give an obvious place to find apps that have particular functionality (try searching for "games that don't need wifi" in the Play Store). 
• give developers an obvious place to find large numbers of users. 
• give developers a structured mechanism for exposing the features of their app so that users can filter the set of available apps for apps that have those features. 
• give users an obvious place to review apps. 
• give developers an obvious place to accrue reputation for their apps. 
• give platform vendors a place to assert policies that drive developer behaviour.
• give every app on a platform a canonical URL ( for example here are iOS and Android URLs for the same game).

Do you remember how painful native mobile apps were (for users and developers) before the popularity of app stores?

— Adewale Oshineye (@ade_oshineye) June 27, 2016

It's easy to forget that app stores emerged as a response to the difficulties of dealing with carriers to get your content 'on deck', getting your apps preinstalled and the extremely closed nature of that ecosystem. However that's not the job to be done on today's web. Instead what we need is:

• a plurality of voices and projects pushing the web forwards. 
• a mechanism where submitting a PWA is as easy as providing a URL therefore anyone can do it.
• a mechanism where web sites and web apps don't have to provide anything proprietary in order to have a chance of being featured.
• to build upon the lessons learned from Mozilla's Firefox Marketplace and Chrome's Web Store.
• something that feels like it's part of the hypertextual web of links rather than a poor copy of native app stores.

Instead of 'cargo culting' the app stores we should be asking what web-centric solutions to the problem would look like. For me that means lots of competing and opinionated PWA directories rather than one central PWA Store or even a popular search engine.

All curation grows until it requires search. All search grows until it requires curation.

— Benedict Evans (@BenedictEvans) December 18, 2015

The Social Stack: what’s in and what’s out at the various layers

I wrote this back in late 2010 from August to November. This was around the time of the first and only OpenWebFoo so I was trying to think through the stack of specifications, protocols and standards that would have let us build a federated social web.

I've ensured that all the links still work as of June 2016 but apart from that this represents what I believed all those years ago. I'm posting it here because I want to remember the past. At the same time it's a marker of the end of that particular phase of my life.

Today I can clearly see the connection between

• Scott Rosenberg's thoughts about the 'web parenthesis'
• the painfully slow evolution of my thinking about the intrinsic and predictive value of openness
• the techocratic web we rejected
• the closing of the 'browser parenthesis'

At the time I remember pointing out the incongruity of a closed event about the open and social web. In hindsight I should have been asking questions:

• Who isn't represented in this room?
• Why is that?
• What will be the consequences?

---

Discovery
Prefer WebFinger

Security: Identity
OpenId

Relationships
XFN

Security: Authentication
OpenID Connect 

Security: Authorisation
Prefer OpenID Connect/OAuth2

Cross-Site Syndication
Activity Streams
Salmon

Syndication
Prefer Activity Streams (Atom or JSON) over simple Atom or RSS

Realtime syndication
Prefer PubSubHubbub

Profile Data
Prefer Portable Contacts
hCard