Recent blog entries for ade

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.
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.


Syndicated 2016-10-25 16:44:00 (Updated 2016-10-25 16:44:10) from Ade Oshineye

2 Aug 2016 (updated 4 Aug 2016 at 10:09 UTC) »

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.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!