tag:blogger.com,1999:blog-38044784179384458962024-03-05T17:01:46.370+00:00Heuristic Outcomes by Ade OshineyeSoftware craftsmanship, photography and heuristics.Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.comBlogger80125tag:blogger.com,1999:blog-3804478417938445896.post-32866307076298584812017-12-08T15:43:00.001+00:002017-12-08T15:44:52.216+00:00Why are the presenter notes ugly when I export them as PDFs from Keynote?<div dir="ltr" style="text-align: left;" trbidi="on">
I use Keynote and I like it. However like many other professional-grade products from Apple it seems to to be changing in ways that make it less suited to my needs.<br />
<a data-flickr-embed="true" href="https://www.flickr.com/photos/adewale_oshineye/38879461112/in/dateposted-public/" title="Ugly PDF export from Keynote 7.3.1"><img alt="Ugly PDF export from Keynote 7.3.1" height="295" src="https://farm5.staticflickr.com/4596/38879461112_c48b496f63.jpg" width="500" /></a><script async="" charset="utf-8" src="//embedr.flickr.com/assets/client-code.js"></script>
<br />
In Keynote 09 I can easily export a good looking PDF with presenter notes and upload it to <a href="https://speakerdeck.com/adewale">Speakerdeck</a> or <a href="https://www.slideshare.net/adeoshineye">Slideshare</a>.<br />
<br />
In Keynote 7.3.1 that's no longer possible. All you can do is export a PDF with presenter notes that take up more than 50% of the page. Or you can export something decent-looking but it won't have presenter notes.<br />
<br />
There's an <a href="http://www.openradar.me/21785935">OpenRadar issue </a>for it but it's been open since July 2015 and it still hasn't been fixed.<br />
<br />
That leaves people like me with a limited set of options.<br />
<ol style="text-align: left;">
<li>Stop using Keynote.</li>
<li>Go back to using Keynote 09.</li>
<li>Use Keynote 7.3.1 then export to Keynote 09 format and from Keynote 09 export a PDF.</li>
<li>Export a PDF without speaker notes and hope that people will wait for the video of your presentation to be available.</li>
<li>Adopt <a href="https://meowni.ca/posts/presenter-notes-that-dont-suck/">Monica Dinculescu's approach</a> where you change your slides after the presentation so that your speaker notes are part of each slide.</li>
</ol>
<div>
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.comtag:blogger.com,1999:blog-3804478417938445896.post-60424487681491769892017-06-14T20:38:00.000+01:002017-06-14T20:38:37.725+01:00Progressive web sites: a future that’s native to the web<div dir="ltr" style="text-align: left;" trbidi="on">
People sometimes claim that the web and native apps are converging. I disagree. I think the process is more like chiasmus in the sense that we will end up with an app-like web and a web-like app ecosystem but they'll still be different from each other. The two ecosystems will cross over but the results will have surprising new capabilities and unlock <a href="https://www.youtube.com/watch?v=J8Hj5bIYuYA&t=221">new metaphors</a> for thinking about them.<br />
<br />
In the meantime we are stuck in <a href="https://cloudfour.com/thinks/designing-responsive-progressive-web-apps/">an uncanny valley</a> where a lot of the PWAs people know are designed like Android apps rather than trying to be native to the web. One of my colleagues even wrote an article arguing that you should "<a href="https://medium.com/@owencm/designing-great-uis-for-progressive-web-apps-dd38c1d20f7?source=linkShare-ccab0a9f04e-1492962576">start by forgetting everything you know about conventional web design, and instead imagine you’re actually designing a native app.</a>"<br />
<br />
I think we can do better but first we have to imagine a future for the web that isn't just about building native apps in Javascript. This requires a conceptual model that’s native to the web.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="279" src="https://www.youtube.com/embed/J8Hj5bIYuYA" width="496"></iframe>
That conceptual model would assume that people aren't going to arrive at your home page. Instead they'll find your site through search or social which deeplink to a specific page and they won't know if your site is valuable yet. That means they won't be immediately interested in adding your site to their home screen or giving you access to device capabilities (like notifications or location) or waiting whilst a massive Javascript bundle downloads.<br />
<br />
That conceptual model would focus on the uniquely universal reach of the web rather than just what's possible on high-end mobile devices. That's because the first time the user visits your site may be on a desktop and if they get a bad experience they're not going to click on links to your site when they turn up in search results or in a social media context. Even if the first visit happens on a mobile device it may be a low end device or on a flakey network so if they get a bad experience there they definitely won't return in other contexts.
<br />
<blockquote class="twitter-tweet" data-conversation="none" data-lang="en">
<div dir="ltr" lang="en">
What I'm saying is that the value of the web is reach. Adopting tools that make it harder to achieve reach works against you.</div>
— Alex Russell (@slightlylate) <a href="https://twitter.com/slightlylate/status/855817295263784960">April 22, 2017</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
That conceptual model would emphasise URLs, linking to other people's sites and reusing rather than reinventing browser features. For example native apps get Chrome Custom Tabs or SFSafariViewController which are great experiences that encourage linking to the rest of the web. Consequently their developers don’t have to worry about harming retention metrics because it's just one click to get back. But we don't <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=709889">yet</a> have the equivalent for PWAs.
<br />
<a data-flickr-embed="true" href="https://www.flickr.com/photos/adewale_oshineye/34457852354" title="Different contexts for viewing web pages"><img alt="Different contexts for viewing web pages" height="323" src="https://c1.staticflickr.com/5/4206/34457852354_4883069923.jpg" width="500" /></a><script async="" charset="utf-8" src="//embedr.flickr.com/assets/client-code.js"></script>
<br />
So, what do we call this new model? I think Jeremy Keith was right when he coined the phrase <a href="https://adactio.com/journal/11130">Progressive Web Sites</a> because I believe that the best thing about PWAs is that they are part of the web. The trick is that they need to be good websites. This means that a good PWS should:<br />
<ul style="text-align: left;">
<li>use the <a href="https://developers.google.com/web/fundamentals/performance/prpl-pattern/">PRPL pattern</a> to ensure the fastest possible initial experience.</li>
<li>take advantage of PWA techniques and technologies to give the user the best possible experience.</li>
<li>be responsive so that any user on any device can access the site and get a good experience.</li>
<li>be progressively enhanced because the set of capabilities that will be available on the user's device are unknowable.</li>
<li>link liberally and rely on the browser to provide features like sharing, window management and navigation.</li>
<li>default to web-like design tropes and only make the effort to be app-like when it provides a clear benefit.</li>
<li>focus on their own branding (whilst still being responsive to the constraints of the user's context) rather than trying to fit into any given operating system's guidelines.</li>
</ul>
In conclusion I think that most people should be building web-like websites rather than app-like websites. That's because few sites are compelling enough that people will benefit from having instant access via their home screen. If you're Twitter.com then a PWA is the right choice because millions of people want your icon on their homescreen, will launch it every day and want to use device capabilities (like the camera or notifications). However if you're Oshineye.com then a PWS makes much more sense because even I don't want it on my homescreen. Don't think of this as a binary choice. Instead it's a spectrum and you should choose your place on it based on:<br />
<ul style="text-align: left;">
<li>the nature of your traffic. If you depend on traffic from external links, have high bounce rates and low session-depth then you should be leaning towards PWS. If you have lots of direct traffic, low bounce rates and high session-depth then you should be leaning towards a PWA. </li>
<li>the amount of resources you're willing to invest. The less resource-constrained you are the more you should skew towards a PWA.</li>
<li>the <a href="https://www.linkedin.com/pulse/20141104125916-6774233-how-to-use-incremental-roi-to-make-better-marketing-decisions">incremental ROI</a>: If your incremental ROI is small then it doesn't make sense to invest a lot. Given that a PWA is a bigger investment than a PWS you should default to PWS and only make the extra investment to build a PWA if you can clearly articulate the additional benefits you'll get from it.</li>
</ul>
<br />
<div>
</div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-90123366920215073092017-05-30T00:35:00.000+01:002017-05-30T00:35:37.821+01:00PWAs are websites<div dir="ltr" style="text-align: left;" trbidi="on">
<a data-flickr-embed="true" href="https://www.flickr.com/photos/adewale_oshineye/5552844098" title=""We are all just prisoners here of our own device""><img alt=""We are all just prisoners here of our own device"" height="333" src="https://c1.staticflickr.com/6/5263/5552844098_ba02e4e083.jpg" width="500" /></a><script async="" charset="utf-8" src="//embedr.flickr.com/assets/client-code.js"></script>
<br />
I recently saw this <a href="http://sdtimes.com/web-app-model-becomes-progressive/">article in SD Times by Frank J. Ohlhorst which was describing the PWA approach to a new audience</a>. Whilst I'm glad that Frank wrote the article I felt it had a few significant technical inaccuracies or misunderstandings.<br />
<br />
It initially starts strong with lots of elements taken from <a href="https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/">Alex Russell's original blog post</a>. The author then correctly points out that Alex's post didn't tell people about the <a href="https://developers.google.com/web/fundamentals/architecture/app-shell">app shell model</a> or explain <a href="https://developers.google.com/web/fundamentals/getting-started/primers/service-workers">service workers</a>. Then he makes a few errors.<br />
<br />
Firstly PWAs don't work <i>like</i> websites, they <i>are</i> websites.<br />
<br />
As a result they don't require frameworks. Here's the code to a PWA: <a href="https://github.com/GoogleChrome/gulliver">https://github.com/GoogleChrome/gulliver </a>that was built without using a framework. And this is <a href="https://huffduffer.com/">Huffduffer</a>. It's one of my favourite PWAs. It also doesn't use any frameworks. That doesn't mean I think frameworks are bad. Just that whilst frameworks and libraries can help with building great web experiences (like <a href="https://vue-hn.now.sh/top">my favourite interface to Hacker News</a>) they're not essential.<br />
<br />
Another misunderstanding is the claim that PWAs can't support single-sign-on and cross-application logins because "PWAs are unable to independently collect and store that login information." This is incorrect. <a href="https://plus.google.com/">PWAs like Google+</a> already support single-sign-on. Try visiting it in an incognito window, signing-in then visiting another Google property. You'll stay signed in. This is possible because PWAs are just websites.<br />
<br />
Another misunderstanding is the idea that PWAs lack hardware support. PWAs are only limited to the hardware features that browsers can access on each platform. Since <a href="http://blog.oshineye.com/2015/06/closing-the-browser-parenthesis.html">browsers are just native apps like any other</a> the true constraints are in the APIs they choose to expose to web sites. That means <a href="https://caniuse.com/#search=camera">cameras are supported</a> and <a href="https://caniuse.com/#feat=geolocation">so is GPS</a> and so are biometrics. You can try the latter in <a href="https://stripe.com/apple-pay">Stripe's Apple Pay demo</a>.<br />
<br />
There are certainly caveats that should be applied. For instance many of the web APIs for hardware aren't standardised or aren't available in all mainstream modern browsers or aren't as good as the equivalent native APIs. Many of them also don't iterate as fast as the equivalent native APIs. At the same large numbers of people use these capabilities every day in web apps like Facebook, Instagram and Google Maps.<br />
<br />
Finally there's a misunderstanding of Safari's support for PWAs. It's true that Safari currently doesn't support <a href="https://caniuse.com/#feat=serviceworkers">Service Workers</a> or <a href="https://caniuse.com/#feat=web-app-manifest">web app manifests</a> or <a href="https://caniuse.com/#feat=push-api">push notifications</a> but that misses the point of PWAs. The P stands for progressive as in progressive enhancement. That means that a good PWA will still be a good experience on Safari but will be progressively enhanced to be a <i>better</i> experience on browsers that have more features.<br />
<br />
I'm biased since my team at Google built it but I think that a great resource for looking at hundreds of examples of PWAs is <a href="https://pwa-directory.appspot.com/">our PWA Directory</a>. I would also suggest that people take a look at our <a href="https://developers.google.com/web/progressive-web-apps/checklist">PWA Checklist</a> and my colleague <a href="https://www.youtube.com/watch?v=mmq-KVeO-uU">Owen Campbell-Moore's Google I/O 2017 talk</a> to get some tips on how to build a great PWA.<br />
<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-9943260391168515792016-10-25T17:44:00.000+01:002016-10-25T17:44:10.032+01:00Starting a new PWA directory<div dir="ltr" style="text-align: left;" trbidi="on">
<span id="docs-internal-guid-5b73fef3-fc82-b575-7736-7994f7325074"></span><br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span id="docs-internal-guid-5b73fef3-fc82-b575-7736-7994f7325074"><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">A few of us in Google's Developer Relations group are building a little demo: </span><a href="https://pwa-directory.appspot.com/" style="text-decoration: none;"><span style="color: #1155cc; font-family: "arial"; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">pwa-directory.appspot.com</span></a><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> It's </span><a href="https://github.com/GoogleChrome/gulliver" style="text-decoration: none;"><span style="color: #1155cc; font-family: "arial"; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">open source and code named Gulliver</span></a><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> because it's a PWA directory in the spirit of </span><a href="https://en.wikipedia.org/wiki/Yahoo!_Directory" style="text-decoration: none;"><span style="color: #1155cc; font-family: "arial"; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Yahoo</span></a><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> or </span><a href="https://en.wikipedia.org/wiki/DMOZ" style="text-decoration: none;"><span style="color: #1155cc; font-family: "arial"; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">DMOZ</span></a><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">.</span></span></div>
<span id="docs-internal-guid-5b73fef3-fc82-b575-7736-7994f7325074">
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">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 </span><a href="https://pwa.rocks/" style="text-decoration: none;"><span style="color: #1155cc; font-family: "arial"; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">pwa.rocks</span></a><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> PWA directory.</span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmNuksycHgixdylIspC4A1k7zDR_1f8MjUvMLNefQkBwq0LaGaqPkYIIa7kfAvjZVfHUhG2tfcVPl6hWJAHqM7pJzwy0GVMsSYVqB014IomkNFx4uWfJ-uwmuHFN32WChhGDqkH4E82qY/s1600/b51b2399-28a0-41cb-b4e6-dc0b42f51f57.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmNuksycHgixdylIspC4A1k7zDR_1f8MjUvMLNefQkBwq0LaGaqPkYIIa7kfAvjZVfHUhG2tfcVPl6hWJAHqM7pJzwy0GVMsSYVqB014IomkNFx4uWfJ-uwmuHFN32WChhGDqkH4E82qY/s400/b51b2399-28a0-41cb-b4e6-dc0b42f51f57.png" width="223" /></a></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">If there's already another PWA directory why are we doing this and what do we hope to achieve?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">Our primary goal is to learn in the open and share those lessons. Some of the things we hope to learn include:</span></div>
<ul style="margin-bottom: 0pt; margin-top: 0pt;">
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">what makes people use a PWA offline?</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">what constitutes a meaningful offline experience?</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">what percentage of our userbase actually uses it offline?</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">which PWA technologies help with acquisition, engagement, retention and re-engagement of users?</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">how do we build a good cross-platform and cross-browser experience?</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">what signals in analytics and Search Console indicate that we are on the right path?</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">what are the things we believe or assume that are wrong?</span></div>
</li>
</ul>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">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.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">However this isn't a big web app so our stack is relatively simple. </span></div>
<ul style="margin-bottom: 0pt; margin-top: 0pt;">
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">Vanilla.js </span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="https://nodejs.org/" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Node.js</span></a><span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="http://expressjs.com/" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Express.js</span></a></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="http://handlebarsjs.com/" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Handlebars</span></a></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="https://cloud.google.com/appengine/docs/flexible/nodejs/" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Google App Engine Node.js Flexible Environment</span></a></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="https://github.com/GoogleChrome/sw-precache" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Service Worker Precache</span></a></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="https://github.com/GoogleChrome/sw-toolbox" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Service Worker Toolbox</span></a></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="https://cloud.google.com/datastore/" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Google Cloud Datastore</span></a><span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> for general data</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="https://cloud.google.com/storage/" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Google Cloud Storage</span></a><span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> for images only</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 14.6667px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<a href="https://developers.google.com/identity/" style="text-decoration: none;"><span style="color: #1155cc; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Google sign-in</span></a><span style="font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> as an anti-spam hurdle for those submitting new sites.</span></div>
</li>
</ul>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">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 <a href="https://github.com/GoogleChrome/lighthouse">Lighthouse</a> 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 </span><a href="https://github.com/GoogleChrome/gulliver/issues/204" style="text-decoration: none;"><span style="color: #1155cc; font-family: "arial"; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">an open issue</span></a><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> and we’re working on it.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;">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 </span><a href="https://github.com/GoogleChrome/gulliver" style="text-decoration: none;"><span style="color: #1155cc; font-family: "arial"; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">get in touch with us via Github</span></a><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"> if you have questions or feature requests.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
</span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhP5zRHXZAOZN0VX-bVni7AhQJ5H2ljFCBM0IZaTSFVogGZ-1msmNCMWZXWo3S3MOYGmy4S3pqRw31vm3fEoY6_gFrJNO-6fEeZEz-CccKxK08_VBS78-WuMKHMb4oDG-5nmevDcBo5Ulw/s1600/Screen+Shot+2016-10-25+at+5.13.22+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="185" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhP5zRHXZAOZN0VX-bVni7AhQJ5H2ljFCBM0IZaTSFVogGZ-1msmNCMWZXWo3S3MOYGmy4S3pqRw31vm3fEoY6_gFrJNO-6fEeZEz-CccKxK08_VBS78-WuMKHMb4oDG-5nmevDcBo5Ulw/s400/Screen+Shot+2016-10-25+at+5.13.22+PM.png" width="400" /></a></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-43270692810210924622016-08-02T14:48:00.000+01:002016-08-04T10:42:48.972+01:00Embeds, content and context<div dir="ltr" style="text-align: left;" trbidi="on">
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 <a href="https://twitter.com/search?q=%23peakrss">#PeakRSS</a> 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.
<br />
<br />
To maximise the reach of your content you have to reduce the accidental friction (see <a href="https://en.wikipedia.org/wiki/No_Silver_Bullet">Brooks on the difference between essential and accidental properties</a>) 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.<br />
<br />
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.<br />
<br />
<div class="tumblr-post" data-did="7b31cb70d2113e6025afba8db88246b71341177f" data-href="https://embed.tumblr.com/embed/post/_aM1XLCvm3xG9VoLHglB5w/148169494570">
<a href="http://parochialaesthetics.tumblr.com/post/148169494570/eliel-saarinen-always-design-things-by-context">http://parochialaesthetics.tumblr.com/post/148169494570/eliel-saarinen-always-design-things-by-context</a></div>
<script async="" src="https://secure.assets.tumblr.com/post.js"></script>
This can range from music players (like <a href="https://soundcloud.com/pages/embed">Soundcloud</a>) to video players (<a href="https://developers.google.com/youtube/iframe_api_reference">like YouTube</a>) to quotes (<a href="https://dev.twitter.com/web/embedded-tweets">like Twitter</a>) to whole discussion threads (<a href="https://developers.google.com/+/web/embedded-post/">like Google+</a>). What distinguishes them from <a href="https://medium.com/@cdixon/nine-reasons-screenshots-are-awesome-88d9a8b2f8b0">glorified screenshots</a> or <a href="https://en.wikipedia.org/wiki/Transclusion">Xanadu's transclusions</a> is their interactivity. Visitors to your site can interact with this foreign content without abandoning your site.<br />
<br />
But isn't this what links are supposed to do? Unfortunately inline links have various problems:
<br />
<ul style="text-align: left;">
<li>they take the user away from your site</li>
<li>they break silently</li>
<li>the content at the destination has to be consumed without the context provided by your site</li>
<li>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</li>
</ul>
Embeds don't have these problems. They:
<br />
<ul style="text-align: left;">
<li>keep the user on your site</li>
<li>break in ways that are immediately visible</li>
<li>are consumed in the context provided by your site</li>
<li>can be constrained to a tiny card with a predictable UX within your site </li>
</ul>
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:
<br />
<ul style="text-align: left;">
<li>convert your social efforts into traffic on your site </li>
<li>help you keep people engaged with your site</li>
<li>help you increase the reach of your content</li>
<li>help you use other people's content to enrich your site</li>
</ul>
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.
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-54045861969511348532016-07-20T16:01:00.000+01:002016-07-20T18:41:36.571+01:00Art, AI and Google I/O 2016<div dir="ltr" style="text-align: left;" trbidi="on">
What if there are interesting things waiting to be discovered where artificial intelligence meets art?<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/egk683bKJYU" width="560"></iframe>
At Google I/O 2016 <a href="https://www.linkedin.com/in/ramzirizk">Ramzi Rizk</a> told me there's a field called <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.9641&rep=rep1&type=pdf">Computational Aesthetics.</a> 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 <a href="https://www.flickr.com/explore/interesting/">Flickr's Interestingness</a> 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 <a href="https://www.technologyreview.com/s/537741/computational-aesthetics-algorithm-spots-beauty-that-humans-overlook/">research showing that social signals lead communities like Flickr to overlook hidden gems</a>. This research raises the tantalising possibility that there may be large numbers of overlooked masterpieces hiding in the historical corpus of art.<br />
<br />
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 <a href="https://www.youtube.com/watch?v=egk683bKJYU&feature=youtu.be&t=2001">the spatial visualisation used in the "Machine learning & art"</a> talk at I/O lead me to <a href="https://en.wikipedia.org/wiki/T-distributed_stochastic_neighbor_embedding">t-SNE</a> as a mechanism for building two-dimensional maps of high-dimensional spaces.<br />
<br />
This raises the possibility of building pirate maps of information spaces or hypertexts and connecting that to <a href="https://en.wikipedia.org/wiki/Memex#Associative_trails">Vannevar Bush's ideas about stigmergy in the Memex</a>. 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.<br />
<!-- Place this tag in your head or just before your close body tag. -->
<script src="https://apis.google.com/js/plusone.js" type="text/javascript"></script>
<!-- Place this tag where you want the widget to render. -->
<br />
<div class="g-post" data-href="https://plus.google.com/+AdeOshineye/posts/4iJLPz7xrsf">
</div>
<br />
Today apps like <a href="http://prisma-ai.com/">Prisma</a> merely help us make alternative versions of existing photos. At the same time apps like <a href="https://itunes.apple.com/gb/app/roll-automatically-organize/id1051300668?mt=8">The Roll</a> and <a href="https://photos.google.com/">Google Photos</a> 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.<br />
<br />
<blockquote class="instagram-media" data-instgrm-captioned="" data-instgrm-version="7" style="background: #fff; border-radius: 3px; border: 0; box-shadow: 0 0 1px 0 rgba(0 , 0 , 0 , 0.5) , 0 1px 10px 0 rgba(0 , 0 , 0 , 0.15); margin: 1px; max-width: 658px; padding: 0; width: 99.375%;">
<div style="padding: 8px;">
<div style="background: #F8F8F8; line-height: 0; margin-top: 40px; padding: 50.0% 0; text-align: center; width: 100%;">
<div style="background: url(data:image/png; display: block; height: 44px; margin: 0 auto -44px; position: relative; top: -22px; width: 44px;">
</div>
</div>
<div style="margin: 8px 0 0 0; padding: 0 4px;">
<a href="https://www.instagram.com/p/BH-tkZDh7Wl/" style="color: black; font-family: "arial" , sans-serif; font-size: 14px; font-style: normal; font-weight: normal; line-height: 17px; text-decoration: none; word-wrap: break-word;" target="_blank">Playing with #prisma (and a little bit of Clarendon) on this #latergram from #io16</a></div>
<div style="color: #c9c8cd; font-family: Arial,sans-serif; font-size: 14px; line-height: 17px; margin-bottom: 0; margin-top: 8px; overflow: hidden; padding: 8px 0 7px; text-align: center; text-overflow: ellipsis; white-space: nowrap;">
A photo posted by Ade Oshineye (@ade_oshineye) on <time datetime="2016-07-17T22:47:06+00:00" style="font-family: Arial,sans-serif; font-size: 14px; line-height: 17px;">Jul 17, 2016 at 3:47pm PDT</time></div>
</div>
</blockquote>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-63037836230773666912016-06-29T12:39:00.000+01:002016-06-29T12:39:40.764+01:00Cargo cults and progressive web app stores<div dir="ltr" style="text-align: left;" trbidi="on">
<a data-flickr-embed="true" href="https://www.flickr.com/photos/adewale_oshineye/7300555264/in/album-72157629964816904/" title="Every city needs a curator"><img alt="Every city needs a curator" height="333" src="https://c1.staticflickr.com/8/7227/7300555264_d04c59ff61.jpg" width="500" /></a><script async="" charset="utf-8" src="//embedr.flickr.com/assets/client-code.js"></script><br />
People are seeing that <a href="https://adactio.com/journal/10800">native app platforms have some feature</a> and are then asking for the exact same feature for the web. Instead they should be asking about the <a href="http://www.christenseninstitute.org/key-concepts/jobs-to-be-done/">job to be done</a> and the benefits users or developers see from a given feature. For example app stores :<br />
<ul style="text-align: left;">
<li>give an obvious place to find apps that have particular functionality (try searching for <a href="https://play.google.com/store/search?q=%22games%20that%20don%27t%20need%20wifi%22">"games that don't need wifi"</a> in the Play Store). </li>
<li>give developers an obvious place to find large numbers of users. </li>
<li>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. </li>
<li>give users an obvious place to review apps. </li>
<li>give developers an obvious place to accrue reputation for their apps. </li>
<li>give platform vendors a place to assert policies that drive developer behaviour.</li>
<li>give every app on a platform a canonical URL ( for example here are <a href="https://itunes.apple.com/gb/app/sky-force-reloaded/id976116090?mt=8">iOS</a> and <a href="https://play.google.com/store/apps/details?id=pl.idreams.SkyForceReloaded2016">Android</a> URLs for the same game).</li>
</ul>
<blockquote class="twitter-tweet" data-lang="en">
<div dir="ltr" lang="en">
Do you remember how painful native mobile apps were (for users and developers) before the popularity of app stores?</div>
— Adewale Oshineye (@ade_oshineye) <a href="https://twitter.com/ade_oshineye/status/747357149878194176">June 27, 2016</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
It's easy to forget that app stores emerged as a response to <a href="https://www.imediaconnection.com/articles/ported-articles/red-dot-articles/2007/may/wireless-media-planning-on-deck-vs-off/">the difficulties of dealing with carriers to get your content 'on deck'</a>, <a href="https://books.google.co.uk/books?id=U7UPjbPJCLYC&pg=PA9&lpg=PA9&dq=on+deck+carriers+apps&source=bl&ots=X1Zp3H1ZH5&sig=HL-WRJ0Wn6JJyOvpmL3BPZhu6RU&hl=en&sa=X&ved=0ahUKEwj048vgjMjNAhWHHsAKHZKlBwkQ6AEIKjAC#v=onepage&q=on%20deck%20carriers%20apps&f=false">getting your apps preinstalled</a> and <a href="http://blog.cloudfour.com/carriers-app-store-and-mobile-web-six-factors-for-app-distribution-success/">the extremely closed nature of that ecosystem</a>. However that's not the job to be done on today's web. Instead what we need is:
<br />
<ul style="text-align: left;">
<li>a plurality of voices and projects pushing the web forwards. </li>
<li>a mechanism where submitting a PWA is as easy as providing a URL therefore anyone can do it.</li>
<li>a mechanism where web sites and web apps don't have to provide anything proprietary in order to have a chance of being featured.</li>
<li>to build upon the lessons learned from Mozilla's <a href="https://marketplace.firefox.com/">Firefox Marketplace</a> and Chrome's <a href="https://chrome.google.com/webstore/">Web Store</a>.</li>
<li>something that feels like it's part of the <a href="http://www.tformaro.com/thesis/">hypertextual web of links</a> rather than a poor copy of native app stores.</li>
</ul>
Instead of '<a href="https://en.wikipedia.org/wiki/Cargo_cult">cargo culting</a>' 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.<br />
<blockquote class="twitter-tweet" data-lang="en">
<div dir="ltr" lang="en">
All curation grows until it requires search. All search grows until it requires curation.</div>
— Benedict Evans (@BenedictEvans) <a href="https://twitter.com/BenedictEvans/status/677977465373896704">December 18, 2015</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-35579816771933949002016-06-10T01:36:00.000+01:002016-06-10T01:36:00.124+01:00The Social Stack: what’s in and what’s out at the various layers<div dir="ltr" style="text-align: left;" trbidi="on">
I wrote this back in late 2010 from August to November. This was around the time of the first and only <a href="http://lanyrd.com/2010/open-web-foo/">OpenWebFoo</a> so I was trying to think through the stack of specifications, protocols and standards that would have let us build a federated social web.<br />
<br />
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.<br />
<br />
Today I can clearly see the connection between<br />
<ul style="text-align: left;">
<li><a href="http://www.wordyard.com/2010/10/12/the-web-parenthesis-is-the-open-web-closing/">Scott Rosenberg's thoughts about the 'web parenthesis'</a></li>
<li><a href="http://blog.oshineye.com/2013/04/open-always-wins.html">the painfully slow evolution of my thinking about the intrinsic and predictive value of openness</a></li>
<li><a href="http://blog.oshineye.com/2013/03/what-do-you-mean-we.html">the techocratic web we rejected</a></li>
<li><a href="http://blog.oshineye.com/2015/06/closing-the-browser-parenthesis.html">the closing of the 'browser parenthesis'</a></li>
</ul>
<br />
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:<br />
<ul style="text-align: left;">
<li>Who isn't represented in this room?</li>
<li>Why is that?</li>
<li>What will be the consequences?</li>
</ul>
<br />
<a data-flickr-embed="true" href="https://www.flickr.com/photos/tantek/5302512039/" title="IMG_1234"><img alt="IMG_1234" height="281" src="https://c8.staticflickr.com/6/5001/5302512039_4dc21aec62.jpg" width="500" /></a><script async="" charset="utf-8" src="//embedr.flickr.com/assets/client-code.js"></script>
<br />
<hr />
Discovery<br />
Prefer <a href="https://webfinger.net/">WebFinger</a><br />
<br />
Security: Identity<br />
<a href="http://openid.net/">OpenId</a><br />
<br />
Relationships<br />
<a href="http://gmpg.org/xfn/">XFN</a><br />
<br />
Security: Authentication<br />
<a href="http://openid.net/connect/">OpenID Connect </a><br />
<br />
Security: Authorisation<br />
Prefer <a href="http://openid.net/connect/">OpenID Connect</a>/<a href="http://wiki.oauth.net/OAuth-2">OAuth2</a><br />
<br />
Cross-Site Syndication<br />
<a href="http://activitystrea.ms/">Activity Streams</a><br />
<a href="http://www.salmon-protocol.org/">Salmon</a><br />
<br />
Syndication<br />
Prefer <a href="http://activitystrea.ms/">Activity Streams</a> (<a href="https://tools.ietf.org/html/rfc4287">Atom</a> or <a href="http://www.json.org/">JSON</a>) over simple <a href="https://tools.ietf.org/html/rfc4287">Atom</a> or <a href="http://www.rssboard.org/rss-specification">RSS</a><br />
<br />
Realtime syndication<br />
Prefer <a href="http://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.4.html">PubSubHubbub</a><br />
<br />
Profile Data<br />
Prefer <a href="https://en.wikipedia.org/wiki/Portable_Contacts">Portable Contacts</a><br />
<a href="http://microformats.org/wiki/hcard">hCard</a><br />
<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-58299399862725121272015-09-30T08:51:00.000+01:002015-10-26T18:13:31.319+00:00Guide to implementing App Linking on Android 6.0 Marshmallow<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<a data-flickr-embed="true" href="https://www.flickr.com/photos/adewale_oshineye/8683603856/" title="Knives and forks"><img alt="Knives and forks" height="375" src="https://farm9.staticflickr.com/8265/8683603856_8078ddaaab.jpg" width="500" /></a><br />
<span style="line-height: 22.08px;">Android Marshmallow has a feature that can make life better for developers who feel that their app experience is better than their web experience. It's called</span><span style="line-height: 22.08px;"> <a href="https://developer.android.com/training/app-links/index.html">App Linking</a> and it ensures that your app always handles links for your domain without the disambiguation dialog you would normally see. </span><br />
<span style="line-height: 22.08px;"><a data-flickr-embed="true" href="https://www.flickr.com/photos/adewale_oshineye/21830113332" title="This is the disambiguation dialog I see when I click on a link to Stack Overflow."><img alt="This is the disambiguation dialog I see when I click on a link to Stack Overflow." height="800" src="https://farm6.staticflickr.com/5818/21830113332_eba64838b5_c.jpg" width="450" /></a><script async="" charset="utf-8" src="//embedr.flickr.com/assets/client-code.js"></script></span>
<span style="line-height: 22.08px;">The feature is called App Linking but the connection between the app and the web site is called an App Link. And, in case you're wondering, it's unrelated to Facebook's <a href="http://applinks.org/">AppLinks.org</a> initiative.</span><br />
<span style="line-height: 22.08px;"><br /></span>
<span style="line-height: 22.08px;">This is a short guide to implementing and testing the feature. Let's start.</span><br />
<ol style="text-align: left;">
<li><span style="line-height: 22.08px;">Go through your manifest and identify the domains (and subdomains) your app claims to be able to support.</span></li>
<li><span style="line-height: 22.08px;">Add an <a href="https://developers.google.com/digital-asset-links/v1/getting-started">assetlinks.json</a> file pointing to your app (or apps) to each of these domains or subdomains. If there's a domain or subdomain that you don't control then the verification process will fail. You can either remove that host from your manifest or you can remove the </span><a href="http://developer.android.com/reference/android/content/Intent.html#CATEGORY_BROWSABLE" style="line-height: 22.08px;">CATEGORY_BROWSABLE category</a><span style="line-height: 22.08px;"> from the manifest as this will have the same effect: your app won't intercept request for other people's domains or subdomains.</span></li>
<li><span style="line-height: 22.08px;">Make sure you serve the assetlinks.json file over HTTPS on every domain or subdomain that you support. Your entire site doesn't have to support HTTPS. Serving just the assetlinks.json file over HTTPS will suffice.</span></li>
<li class="graf--li" name="1060">Make sure the assetlinks.json file is served with content-type “application/json” since it won’t work with any other content type.</li>
<li><span style="line-height: 22.08px;">As documented </span><a href="https://developer.android.com/preview/features/app-linking.html#test-dal-files" style="line-height: 22.08px;">here</a><span style="line-height: 22.08px;"> you should use our debugging tool to verify that each domain or subdomain has a valid assetlinks.json file. Here's </span><a href="https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://applinkingexperiment.appspot.com&relation=delegate_permission/common.handle_all_urls" style="line-height: 22.08px;">an example for one of my sites</a><span style="line-height: 22.08px;">.</span></li>
</ol>
<span style="line-height: 22.08px;">If everything works you should see a message like this:</span><br />
<script src="https://gist.github.com/adewale/f7b18587167e4ea4ba81.js"></script>
<span style="line-height: 22.08px;">Add an autoVerify attribute to the intents in your manifest for each of these domains.</span><br />
<script src="https://gist.github.com/adewale/e69809ff4442d0263441.js"></script>
<span style="line-height: 22.08px;">Be aware that the verifier doesn't follow redirects so it won't work if you try to shortcut this by having one canonical file that all the other URLs redirect towards. You can find more details about the install-time verification process by reading this <a href="https://chris.orr.me.uk/android-app-linking-how-it-works/">excellent but now outdated guide from Christopher Orr</a>.</span><br />
<span style="line-height: 22.08px;"><br /></span>
<span style="line-height: 22.08px;">Don't forget that all of these files must match exactly so if you update one of them you must update all of them. Fortunately the SHA256 in the assetlinks.json is based on your app's private keys so once you've added your release and debug keys you should never need to change it.</span><br />
<span style="line-height: 22.08px;"><br /></span>
<span style="line-height: 22.08px;">Between this guide and <a href="https://developer.android.com/training/app-links/index.html">the official documentation</a> you now know everything you need to make App Linking work on Android Marshmallow. If you still have any questions then ask on Stack Overflow using the tag: </span><span style="line-height: 22.08px;"><a href="http://stackoverflow.com/questions/tagged/android-app-linking">android-app-linking</a>.</span></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-88211784704824742332015-06-19T01:11:00.001+01:002015-06-26T21:57:20.273+01:00Omnivorous inclusiveness and the closing of the browser parenthesis<div dir="ltr" style="text-align: left;" trbidi="on">
In the past I've thought of the web as <a href="https://plus.google.com/+AdeOshineye/posts/SV7BJuTdpMR">a convoy of browsers</a>. That turns out to be wrong.<br />
<br />
Nowadays (thanks to a long lunch with <a href="https://twitter.com/psd">Paul Downey</a>, <a href="https://twitter.com/JeniT">Jeni Tennison</a>, et al) I've begun thinking of the web as <a href="https://en.wikipedia.org/wiki/Ship_of_Theseus">a ship of Theseus</a> where, despite replacing every single part of the stack, what's left is still recognisably the web.<br />
<br />
This made me realise that we are surrounded by unexamined and ossified metaphors that are in danger of becoming thought-terminating cliches. For example:<br />
- open web versus (presumably) closed web<br />
- the web browser is the web platform is the web<br />
- the web as a platform<br />
- web <i>apps</i><br />
- web versus native<br />
<br />
<script async="" class="speakerdeck-embed" data-id="5204c0edec6d4353832e091396f4e292" data-ratio="1.67047308319739" src="//speakerdeck.com/assets/embed.js"></script>
One of the reasons I present at conferences like <a href="http://www.opentech.org.uk/">OpenTech</a> is because I want to have my mind changed and my complacent metaphors jolted. This year my presentation came out of asking myself "what do I most like about the web?" My initial list was:<br />
- its universality (view source meant everybody everywhere could cut and paste their way to something that sort of worked).<br />
- its omnivorous inclusiveness (it tended to absorb neighbouring or competing technologies like WAIS, Gopher, NNTP and FTP).<br />
- its hypertextuality, <a href="https://en.wikipedia.org/wiki/Intertwingularity">intertwingularity</a> and document orientation because they open the door to <a href="http://www.tformaro.com/thesis/">new forms of argumentation</a> as well as letting us create living documents.<br />
- its peculiar notion of addressability without guarantees about the nature of the resources at the end of the links.<br />
<br />
This presentation started out as my oft-repeated but never documented "HTML 3.2 was the last good version of HTML" rant. It channeled some of my distress with the ideas behind HTML 5 and the notion that there is a "web platform" which arbitrarily excludes certain technologies (like Flash and native apps) but includes others (like JavaScript). In its final form it asked if today's open web platform is still the web. Now I have my answer.<br />
<br />
That answer is driven by two realisations. Firstly it turns out that browsers are not the only user agent. They're not even the only <i>kind</i> of user agent. Secondly now that <a href="https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_2">deeplinking is becoming mere linking</a> it is clearer than ever that apps are just domain-specific user-agents. As a consequence it becomes clear that native versus web is merely a debate about whether we should use 1 universal user-agent or N domain-specific user-agents.<br />
<br />
Since browsers and native apps are merely different kinds of user-agents I think it's a mistake to conflate browsers and the web. I think we run the risk of mistaking the capabilities and roadmap of today's most popular kind of user agent for the capabilities and roadmap of the web. For example user-agents that don't support Javascript or CSS are equally legitimate but less popular constituents of the web. However there's a strong temptation to consider them to be obsolete or lagging members of our convoy and thus leave them behind.<br />
<br />
<a href="https://www.tbray.org/ongoing/When/201x/2015/04/11/So-What">So</a>.<br />
<br />
The web has changed, is changing and will keep on changing. The convoy is bigger than I originally thought because there are lots of overlooked user-agents out there. These apps aren't part of the web any more than browsers are but their addressable/linkable content most definitely is part of the web. Just because that content has a preferred user-agent doesn't change this.<br />
<br />
Perhaps, like the <a href="http://web.mit.edu/comm-forum/mit5/papers/pettitt_plenary_gutenberg.pdf">Gutenberg Parenthesis</a>, there is a 'Browser Parenthesis' that is also closing?
<br />
<br />
<object height="300" width="400"> <param name="flashvars" value="offsite=true&lang=en-us&page_show_url=%2Fphotos%2Fadewale_oshineye%2Fsets%2F72157654756749415%2Fshow%2F&page_show_back_url=%2Fphotos%2Fadewale_oshineye%2Fsets%2F72157654756749415%2F&set_id=72157654756749415&jump_to="></param>
<param name="movie" value="https://www.flickr.com/apps/slideshow/show.swf?v=1811922554"></param>
<param name="allowFullScreen" value="true"></param>
<embed type="application/x-shockwave-flash" src="https://www.flickr.com/apps/slideshow/show.swf?v=1811922554" allowFullScreen="true" flashvars="offsite=true&lang=en-us&page_show_url=%2Fphotos%2Fadewale_oshineye%2Fsets%2F72157654756749415%2Fshow%2F&page_show_back_url=%2Fphotos%2Fadewale_oshineye%2Fsets%2F72157654756749415%2F&set_id=72157654756749415&jump_to=" width="400" height="300"></embed></object>
<br />
<br />
Update: The <a href="http://www.opentech.org.uk/2015/audio/C6-all-3.mp3#t=950">audio from my OpenTech 2015 talk</a> is now available.</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-28856467525408858482015-01-02T19:31:00.000+00:002015-01-02T19:31:12.307+00:00Awkward questions for those boarding the microservices bandwagon<div dir="ltr" style="text-align: left;" trbidi="on">
Why isn't this <a href="http://www.drmaciver.com/2014/03/write-libraries-not-services/">a library</a>?<br />
What heuristics do you use to decide when to build (or extract) a service versus building (or extracting) a library?<br />
<br />
How do you plan to deploy your microservices?<br />
What is your deployable unit?<br />
Will you be deploying each microservice in isolation or deploying the set of microservices needed to implement some business functionality?<br />
Are you capable of deploying different instances (where an instance may represent multiple processes on multiple machines) of the same microservice with different configurations?<br />
<br />
Is it acceptable for another team to take your code and spin up another instance of your microservice?<br />
Can team A use team B's microservice or are they only used within rather than between teams?<br />
Do you have <a href="http://martinfowler.com/articles/consumerDrivenContracts.html">consumer contacts</a> for your microservices or is it the consumer's responsibility to keep up with the changes to your API?<br />
<br />
Is each microservice a snowflake or are there common conventions?<br />
How are these conventions enforced?<br />
How are these conventions documented?<br />
What's involved in supporting these conventions?<br />
Are there common libraries that help with supporting these conventions?<br />
<br />
How do you plan to monitor your microservices?<br />
How do you plan to trace the interactions between different microservices in a production environment?<br />
<br />
What constitutes a production-ready microservice in your environment?<br />
What does the smallest possible deployable microservice look like in your environment?</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-59485071685237535382015-01-02T19:30:00.001+00:002015-01-02T19:30:34.689+00:002015 technology wishlist<div dir="ltr" style="text-align: left;" trbidi="on">
<iframe allowfullscreen="" frameborder="0" height="375" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" src="https://www.flickr.com/photos/adewale_oshineye/10306675273/in/set-72157629964816904/player/" webkitallowfullscreen="" width="500"></iframe>
The start of the year is a good time to be thinking about the end of the year and the kind of world I would like to see. Usually this leads to resolutions and predictions. Unfortunately I find most predictions worthless since the pundits seldom <a href="https://plus.google.com/communities/111708414670517363238">go back to check on their previous predictions</a>. The other problem is that people start out making predictions and then the articles turn into wishlists. That's why this year I'm just going to write a wishlist.<br />
<br />
I'd like to see:
<br />
<ul style="text-align: left;">
<li>more <a href="http://blog.oshineye.com/2013/09/minimum-viable-identity-provider.html">viable identity providers</a>.</li>
<li>more social environments that understand the benefits of Reed's Law and <a href="http://radio-weblogs.com/0110772/2002/10/09.html">ridiculously easy group-forming</a>.</li>
<li>Wikipedia starting to use identity technology to improve the user experience. For example if I donate or become a member then I'd like to stop seeing obnoxious adverts (and they really are adverts) asking for money. The <a href="https://membership.theguardian.com/">Guardian's membership programme</a> is a good model that Wikipedia should adopt.</li>
<li>a viable successor to the Leica M9. The Leica M Type 240 just isn't a big enough improvement.</li>
<li>a viable replacement for Aperture. I have zero faith in the upcoming Apple Photos app and there isn't enough official support for migrating from Aperture to Lightroom.</li>
<li>a viable replacement for the old Mac Pro. The new Mac Pro abandons all of the strengths of the old Mac Pro.</li>
<li>more <a href="https://plus.google.com/105037104815911535953/posts/dtM4fLsAZNH">mujicomp</a> and less ryanaircomp.</li>
<li>fewer people <a href="http://blog.oshineye.com/2013/03/what-do-you-mean-we.html">bemoaning the web we lost</a> and more people asking new questions about the world we actually live in where <a href="https://vimeo.com/21829271">everything gets touched by the network</a>.</li>
<li>more device-native apps. I'd like to see more apps that are designed to really exploit the capabilities of our current generation of interconnected mobile devices.</li>
<li>more apps that provide multi-device workflows</li>
<li>more experience reports about the issues involved in building backend services that support multiple native mobile and web apps.</li>
<li>the Software Craftsmanship community changing its focus from converting new people to <a href="http://scna.softwarecraftsmanship.com/">helping each other learn and grow</a>.</li>
<li>less hype/advocacy for microservices and more documentation/descriptions of techniques that work with collections of small services. You'll be able to tell if you're seeing hype by the number of <a href="http://blog.oshineye.com/2015/01/awkward-microservices-questions.html">awkward questions</a> that they raise.</li>
</ul>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-29136756502332821312014-12-24T01:42:00.000+00:002014-12-26T13:13:59.678+00:00What makes native mobile apps special?<div dir="ltr" style="text-align: left;" trbidi="on">
<blockquote class="twitter-tweet" lang="en">
Theory: most native mobile apps don't take advantage of the things that make native mobile apps special?<br />
— Adewale Oshineye (@ade_oshineye) <a href="https://twitter.com/ade_oshineye/status/546997873452535808">December 22, 2014</a></blockquote>
That tweet was inspired by a conversation with Scott Jenson in which he asked: "<a href="https://twitter.com/scottjenson/status/545060148813656064">what is mobile good at?</a>" My response was: "<a href="https://twitter.com/ade_oshineye/status/545158018535804928">anything that gets better if you can do it everywhere and add new sensors or transmitters.</a>"<br />
<br />
I think I now have a better answer to a slightly different but more evocative question: <a href="https://twitter.com/ade_oshineye/status/546997893564231680">what makes native mobile apps special?</a><br />
<br />
Firstly these apps are special because they can use every sensor and transmitter on your mobile phone. That means they will also be the first to get access to new sensors and transmitters as they are added to these devices. This gives them more power than any other apps that have ever existed.<br />
<br />
Secondly these apps are special because they're installed in a device that the user will carry around all day every day. That means that they will see more usage per user since there will be so many more opportunities to use them. It may even be time to start measuring average usage per user (AUPU) as a more quantitative version of Larry Page's '<a href="http://x.naveen.com/post/87012828854/first-things-first">toothbrush test.</a>'<br />
<br />
Finally these apps are special because they're on devices that will eventually end up in the hands of every post-pubescent person on the planet. That means they will eventually end up with more users than anything we've seen so far.<br />
<br />
In short...ubiquity.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="333" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" src="https://www.flickr.com/photos/adewale_oshineye/6245129162/player/" webkitallowfullscreen="" width="500"></iframe><br />
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-72984966971549666972013-12-21T12:42:00.004+00:002013-12-21T12:50:18.050+00:00What is the state of the art in Android sharing?<div dir="ltr" style="text-align: left;" trbidi="on">
<iframe allowfullscreen="" frameborder="0" height="500" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" src="https://www.flickr.com/photos/adewale_oshineye/11477759856/player/499280f165" webkitallowfullscreen="" width="313"></iframe><br />
<br />
I meet a lot of people in <a href="http://www.linkedin.com/profile/view?id=1926138">my job</a>. Consequently I get to see lots of different companies trying to create the best possible Android sharing experience. Just about all of them start off with the standard sharing system based on intents and the standard <a href="http://developer.android.com/guide/components/intents-filters.html#ForceChooser">chooser dialog</a>.<br />
<br />
It's compatible with just about all devices but it gives users an alphabetical list of applications even though many of these may not make sense in the given context. For example the list below shows the stock Email app even though I'm a Gmail user who has never configured the other email app on my tablet. This dialog also has issues for users who install lots of apps and its alphabetical ordering means we're starting to see developers gaming the system in order to be at the top of the list.<br />
There's also the problem that the intents system doesn't let you customise the recipient other than by passing in a set of key-value pairs so developers (like The Guardian and Soundwave) offer an explicit Google+ share button in the action bar for users who are signed-in with Google+. This gives their users direct access to interactive posts. They also offer the standard chooser dialog as well.<br />
<br />
The Gallery and Keep apps try to remember the last N apps the user has shared and present them to the user by using <a href="http://android-developers.blogspot.co.uk/2012/02/share-with-intents.html">the ShareActionProvider added in Ice Cream Sandwich</a>. Shazam's implementation is built on the same idea but does something slightly more sophisticated with it. It shows a list of the apps I've recently shared content to but adds various social services to the top of the list. It also knows which social service I signed-in with and adds it to the action bar as a separate button. The assumption is that I'm more likely to want to share newly discovered music to that social network than with the random assortment of apps on my device.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="500" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" src="https://www.flickr.com/photos/adewale_oshineye/11477683404/player/e9d91cbab1" webkitallowfullscreen="" width="313"></iframe><br />
<br />
Snapette and Fancy implement simpler variants on the same idea. They hardcode a small set of social services (including Google+, Twitter and Facebook) even if they're not installed on the user's device. Clicking on those options takes users to a sign-in dialog before they can share. In their defence Fancy does offer a 'More' button that goes to the standard chooser dialog. This offers an escape hatch for users who want to share to contexts other than social networks.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="500" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" src="https://www.flickr.com/photos/adewale_oshineye/11477670975/player/f4cf0545f9" webkitallowfullscreen="" width="313"></iframe><br />
<br />
Another alternative can be seen in the Spotify app. They make their own version of the standard chooser dialog but add a Spotify button to the top. That's because <a href="http://stackoverflow.com/questions/9730243/android-how-to-filter-specific-apps-for-action-send-intent">the standard chooser dialog doesn't give you much control over the order or the membership of the list it uses</a>.<br />
<br />
Unfortunately if you make your own chooser dialog you're going to have to expend a lot of effort to make it resemble the real thing. Or you can just show a simple list.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="500" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" src="https://www.flickr.com/photos/adewale_oshineye/11477776666/player/15c16b0b0d" webkitallowfullscreen="" width="313"></iframe><br />
<br />
So what do I recommend? Ideally you should use the ShareActionProvider but nowadays a lot of apps are finding that <a href="https://developers.google.com/+/features/case-studies">deep integration with social services drives significant traffic and engagement</a>. In that case...<br />
<br />
If the screen is large enough then you should have your preferred share option in the action bar next to a button that launches a custom share list that shows your preferred apps with a More button that sends the user to the standard share dialog. This pushes users towards the developer's preferred networks (these could be the app's network or the services that the user has used to sign-in) but still gives users a way to get to all of apps they've installed.<br />
<br />
On smaller screens you should have a share button that sends the user to a custom list containing the developer's preferred networks with a More button that sends users to the standard chooser dialog.<br />
<br />
This approach balances simplicity of implementation, predictability (users shouldn't have to wonder why options are appearing and disappearing from their chooser dialog), extensibility, value to the developer and responsiveness to device size. This may seem complicated but fortunately a large amount of this can be implemented using the ShareActionProvider and its support for fine-grained tracking of history.<br />
<br />
This is a complex and subtle topic with many different approaches being explored by lots of very smart people. I'm not going to pretend that this blog post is the final answer. After all, there's always the option of building something completely specific to your needs.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="500" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" src="https://www.flickr.com/photos/adewale_oshineye/11477668905/player/50fc14909e" webkitallowfullscreen="" width="313"></iframe></div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-40330758559362701392013-12-11T21:05:00.000+00:002013-12-11T21:05:24.194+00:00Migrating to Google+ Sign-in in 5 minutes<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="p1">
Are you looking to understand the available strategies for migrating your existing Google login solution to <a href="https://developers.google.com/+/web/signin/">Google+ Sign-in</a>? Well… You’ve certainly come to the right place</div>
<div class="p1">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/adewale_oshineye/10011408736/" style="margin-left: 1em; margin-right: 1em;" title="Who are you. You are you by adewale_oshineye, on Flickr"><img alt="Who are you. You are you" src="http://farm8.staticflickr.com/7431/10011408736_e303ccd4f2.jpg" height="500" width="375" /></a></div>
If you're using OpenID1, OpenID2, OAuth1 or OAuth2Login then we have a detailed migration guide: <a href="https://developers.google.com/+/api/auth-migration">https://developers.google.com/+/api/auth-migration</a></div>
<div class="p1">
<br /></div>
<div class="p1">
I strongly recommend reading it. Or at least skimming it since the social login market is bigger and more complicated than it seems. The following is merely a high-level restatement of the migration guide for people who aren't really sure which of the aforementioned technologies they're using.</div>
<div class="p2">
<br /></div>
<div class="p1">
If your existing system captures the user's email address using a Google identity solution then you can just:</div>
<ul class="ul1">
<li class="li1">migrate to Google+ sign-in</li>
<li class="li1">ask for the <a href="https://developers.google.com/+/api/oauth#email-scopes">email OAuth scope</a></li>
<li class="li1">fetch the user's email address using <a href="https://developers.google.com/+/api/auth-migration#email">one of our recommended approaches</a></li>
<li class="li1">look up the user in your database by email</li>
<li class="li1">associate them with the existing record that matches that email address since Google guarantees that the email addresses are valid</li>
</ul>
<div class="p1">
If your existing system doesn't capture the user's email address then life gets interesting.</div>
<div class="p2">
<br /></div>
<div class="p1">
If you're sure you're using OAuth1+OpenID2 then you can follow the instructions here: <a href="https://developers.google.com/+/api/auth-migration#oid2">https://developers.google.com/+/api/auth-migration#oid2</a> which tell you how to fetch your old identifier and find out the equivalent identifier with Google+ Sign. Once that's done you can just associate the new identifier with the existing record and the user can sign-in in future with Google+ Sign-in.</div>
<br />
<div class="p1">
If you're using something else then you can ask the user to sign-in twice: firstly with your existing Google identity solution then with Google+ Sign-in. Now that you have both identities you can associate them in your database. Once a critical mass of your users have gone through this process then you can stop using the legacy identity solution. If you have to use this option then I would also recommend reading Michael Mahemoff's experience report from Player.fm's migration: <span class="s1"><a href="http://softwareas.com/migrating-user-accounts-from-google-openid-to-google-oauth-to-google-plus">http://softwareas.com/migrating-user-accounts-from-google-openid-to-google-oauth-to-google-plus</a> since I got the idea from him.</span></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-40388116265342961992013-11-13T23:54:00.000+00:002013-11-13T23:54:48.164+00:00SCNA 2013 in memes<div dir="ltr" style="text-align: left;" trbidi="on">
What was SCNA 2013 about? Well...the following memes kept coming up.<br />
<div class="p1">
</div>
<ul style="text-align: left;">
<li>10 thousand hours</li>
<li>Dreyfus model</li>
<li>Reasoning by analogy (chess, film making, agriculture)</li>
<li>TDD</li>
<li>Clojure</li>
<li>Code katas</li>
<li>Autonomy, purpose and mastery</li>
<li>Agile</li>
<li>Craftsmanship</li>
<li>Design Patterns</li>
<li>Javascript</li>
<li>Apple Macs</li>
<li>Apprenticeship</li>
<li>Rails</li>
<li>Professionalism</li>
<li>Quality</li>
<li>Community</li>
<li>Family</li>
</ul>
<div>
I also did a little lightning talk in which I tried to get people to change their minds about the Singleton pattern.<br />
<a href="http://www.flickr.com/photos/adewale_oshineye/10835888595/" title="Ceci n'est pas une Singleton by adewale_oshineye, on Flickr"><img alt="Ceci n'est pas une Singleton" height="332" src="http://farm4.staticflickr.com/3725/10835888595_32d4afccca.jpg" width="500" /></a></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-20643178500531564112013-10-07T11:42:00.000+01:002013-10-07T11:42:27.614+01:00The screens in our future<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="p1">
Through historical accident, television has come to be seen as the first screen with our mobile devices as the second screen. This implies a mental model that's usually driven by television people who really mean that television is the primary screen whilst all others are merely secondary screens. When these devices are viewed from the perspective of the programme makers that is correct. But things change if we look at them from the perspective of the user.</div>
<div class="p1">
<blockquote class="twitter-tweet">
The first screen is the one in your pocket. All others are secondary.<br />
— Adewale Oshineye (@ade_oshineye) <a href="https://twitter.com/ade_oshineye/statuses/338627536361771008">May 26, 2013</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script></div>
<div class="p2">
<br /></div>
<div class="p1">
When we look at <a href="http://blog.flurry.com/bid/93898/The-Screen-Bowl-Mobile-Apps-Take-On-TV">usage</a> it becomes clear that mobile devices (currently just phones and tablets) are the primary screen whilst television and desktop computers are the secondary screens.</div>
<div class="p1">
<blockquote class="tr_bq">
Mobile is my screen.<br />
Tablet is our screen.<br />
TV is their screen.</blockquote>
<blockquote class="tr_bq">
-- Simon Davies and Ade Oshineye</blockquote>
</div>
<div class="p1">
The above quote is a synthesis of points made by <a href="http://blogs.bbcworldwide.com/2012/11/15/bbc-worldwide-labs-brings-together-experts-from-the-social-media-sphere-and-start-up-world-to-host-its-first-internet-week-europe-session/">Simon Davies and Ade Oshineye during an Internet Week panel discussion</a>. They reflect a way of looking at screens/devices that may have surprising amounts of explanatory power.</div>
<div class="p2">
<br /></div>
<div class="p1">
The mobile (phone) screen is the most personal screen. It tends to belong to one person who carries it everywhere and seldom shares it. That person will customise it with a combination of apps and bookmarks that's practically a fingerprint. </div>
<div class="p2">
<br /></div>
<div class="p1">
The tablet is large enough to be viewed by multiple people and is often shared within a family. As such it accumulates layers of choices from all the people who have used it. However it still tends to feel like a device that belongs to a small set of people. Whilst both of these devices empower people by giving them control over usage and content, the television is different. </div>
<div class="p2">
<br /></div>
<div class="p1">
Whilst it may belong to one or many you're never allowed to forget that the content on your television is decided by other people. They decide what you can watch and when you can watch it. As for customisation…forget it.</div>
<div class="p2">
<br /></div>
<div class="p1">
The final step is to realise that we shouldn't be thinking about <a href="http://www.bbc.co.uk/blogs/aboutthebbc/posts/connected-storytelling-one-service-ten-products-four-screens">a fixed number of screens</a>. We're facing a <i>multi</i>-screen future. That means there are going to be N categories of M screens in your life. And the values of N and M will only increase over time.<br />
<br />
This is not a problem we will solve by building responsive websites with a fixed number of breakpoints. This is not a even problem we will solve by pouring the same content into a fixed number of buckets or screen sizes.<br />
<br />
This is a <a href="http://en.wikipedia.org/wiki/Cambrian_explosion">Cambrian Explosion</a> of contexts, interactions between contexts and user journeys across contexts. Time to adapt.</div>
<div class="p2">
<br /></div>
<div class="p3">
<span class="s1"><a href="http://www.flickr.com/photos/adewale_oshineye/10133819176/" title="Plenty of room for more screens by adewale_oshineye, on Flickr"><img alt="Plenty of room for more screens" height="375" src="http://farm4.staticflickr.com/3666/10133819176_4dbfd91d4f.jpg" width="500" /></a></span></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-27438268409480129772013-09-30T17:10:00.000+01:002013-10-06T22:07:37.237+01:00Minimum-viable identity provider<div dir="ltr" style="text-align: left;" trbidi="on">
What's required in a minimum-viable IDP (Identity Provider) in 2013?<br />
<br />
When I talk about viability I really mean "competitiveness" and I suppose what I'm really asking is what does it take to get RPs (Relying Parties) to integrate and users to authenticate with an IDP?<br />
<br />
The list of requirements below was first published in <a href="https://speakerdeck.com/adewale/10-themes-in-social-login">a presentation I gave at Over The Air 2013</a>. It's the result of hundreds of conversations with RPs and user over the last few years.<br />
<br class="Apple-interchange-newline" />
<br />
<i>Valuable accounts.</i> Are the accounts attached to real people who have been SMS verified? Does the IDP fight off attempts to create fake and spammy accounts?<br />
<br />
<i>Security</i>. Are the accounts stored using salting and hashing? Do users authenticate using multiple factors? Are precautions being taken to ensure that user accounts are protected?<br />
<br />
<i>Rich profiles</i>. Does the IDP offer data that you can use to personalise your service such as profile data, photos and social/interest graphs?<br />
<br />
<i>Ubiquitous APIs</i>. Does the IDP offer ReSTful APIs, native SDKs, client libraries in various languages and support for RTL languages?<br />
<br />
<i>Escape hatches</i>. Does the IDP lock-in RPs and/or users? Can the RP obtain the user's verified email address so that the user has the option of using a different IDP with the same RP account? Is the RP forced to build their own post-registration flow?<br />
<br />
<i>Business model</i>. Does the IDP make money or otherwise benefit from providing this service? Do they have a compelling incentive to stay in this business?<br />
<br />
The final and most controversial ingredient is scale. Most people would say that all other things being equal an IDP with more accounts is better than an IDP with fewer accounts. I'd suggest that it's better to have accounts that are appropriate to the service the RP is trying to provide. For instance for <a href="http://statigr.am/">Statigram</a> the best IDP is Instagram but for <a href="http://favstar.fm/">Favstar.fm</a> the best IDP is Twitter and, <a href="http://blog.oshineye.com/2010/05/joining-social-web-team.html">of course</a>, for any service that uses Google services (like Youtube, Android, Drive, etc) the best IDP is <a href="https://developers.google.com/+/">Google+</a>.<br />
<br />
The items listed above are just the necessary but not sufficient features of a viable IDP. Successful IDPs will still have to identify and provide <a href="http://blog.oshineye.com/2012/12/the-other-side-of-creating-more-value.html">additional value</a> in order to get widespread adoption by users and RPs.<br /><br />
<script async="" class="speakerdeck-embed" data-id="7c2e86900b280131d1e576d27cbbb36b" data-ratio="1.55386949924127" src="//speakerdeck.com/assets/embed.js"></script>
</div>Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-56618412515139985922013-09-25T22:54:00.000+01:002013-09-25T22:54:09.878+01:00Beyond the NASCAR<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="p1">
People in the identity world worry a lot about the NASCAR problem. </div>
<div class="p1">
<br /></div>
<div class="p1">
<a href="https://www.tbray.org/ongoing/When/201x/2013/09/15/FC6-Who-Are-You">They worry</a> that showing a large set of buttons will hurt conversion rates (because of <a href="http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less">the paradox of choice</a>) and confuse users who don't remember which IDP (identity provider) they used on a particular site+device combination. </div>
<div class="p2">
<br /></div>
<div class="p1">
<a href="http://www.flickr.com/photos/adewale_oshineye/9939544146/" title="Stack Overflow NASCAR by adewale_oshineye, on Flickr"><img alt="Stack Overflow NASCAR" height="216" src="http://farm4.staticflickr.com/3773/9939544146_0ab4fbc794.jpg" width="500" /></a></div>
<div class="p2">
<br /></div>
<div class="p1">
I don't think that's a big problem nowadays. </div>
<div class="p2">
<br /></div>
<div class="p1">
That's because we're down to a fairly small set of viable identity providers (henceforth known as IDPs). Most of the others are either dead(<a href="http://readwrite.com/2011/08/02/rip_openid_janrain_raises_millions_to_do_just_the">MyOpenId</a>), new (<a href="http://login.amazon.com/">Amazon Login</a>) or only useful in specific niches (GitHub, Instagram, Tumblr, LinkedIn etc).</div>
<div class="p2">
<br /></div>
<div class="p1">
If we look at <a href="http://meta.stackoverflow.com/questions/170347/whats-the-breakdown-of-logins-used-on-the-stack-exchange-network">Stack Overflow's data</a> we see that 5 IDPs are used by 98.6% of visitors but everybody has to deal with the cognitive load of choosing between the 12 buttons and 1 form field. </div>
<div class="p2">
<br /></div>
<div class="p1">
Reducing the set of buttons to 3 would still give users a choice whilst reducing cognitive load. By cutting down to just these 3 IDPs they'd have covered the vast majority (in Stack Overflow's case 92.02%) of potential users of their site and greatly simplified the experience. </div>
<div class="p2">
<br /></div>
<div class="p1">
However if you prioritise providing access for 100% of your users over providing the best possible experience for the majority then you have several alternative strategies available to you:</div>
<div class="p1">
<ul style="text-align: left;">
<li>create your own username/password system (but then you have the responsibility of building a first-class security system)</li>
<li>use <a href="http://www.tbray.org/ongoing/When/201x/2012/11/28/AccountChooser">AccountChooser</a></li>
<li>build <a href="https://poetica.com/signin">your own equivalent of AccountChooser or something equally clever</a></li>
<li>use <a href="https://login.persona.org/">Mozilla Persona </a>(although it has various issues that I'll probably write about in the future)</li>
</ul>
</div>
<div class="p1">
If your goal is optimising the percentage of users who sign-in <i>and</i> making sure those people get the best possible experience then here's what I suggest:</div>
<div class="p1">
<br />
<ul style="text-align: left;">
<li>Use Google+ and Facebook buttons (there are also going to be scenarios where Weibo/Renren/VKontakte are appropriate additions). </li>
<li>Then use <a href="https://developers.google.com/+/web/api/javascript#gapiauthchecksessionstatesessionparams_callback">checkSessionState()</a> and <a href="https://developers.facebook.com/blog/post/2012/05/08/how-to--improve-the-experience-for-returning-users/">FB.getLoginStatus()</a> to find out if the user is already signed in to Google or Facebook. The mobile SDKs have equivalent APIs.</li>
<li>Then suggest whichever account the user is already using by putting that button first and/or making it bigger. </li>
</ul>
<br />
We've even published <a href="https://developers.google.com/+/best-practices/facebook">a guide to handling the scenario where the user is signed-in to both IDPs</a> and you can automatically bypass the sign-in screen. </div>
<div class="p2">
<br /></div>
<div class="p1">
However there's still the situation where a user prefers different IDPs on different machines: for instance if they work in a company that blocks Facebook at the firewall or they prefer Google+ on Android but Facebook on iOS. For those users a naive NASCAR implementation leaves them with one account on your service per IDP. </div>
<div class="p2">
<br /></div>
<div class="p1">
The easiest solution to is to ask for the user's email address and use that to correlate all the accounts they use to login to your service. That way the user never has to worry about creating duplicate accounts. Of course this does restrict you to IDPs who can offer a verified email address. </div>
<div class="p2">
<br /></div>
<div class="p1">
The only IDP this excludes is Twitter. If you are using Twitter as an IDP then you'll have to either capture (and verify) the user's email address in a post-registration step. </div>
<div class="p2">
<br /></div>
<div class="p1">
<a href="http://www.flickr.com/photos/adewale_oshineye/8463990561/" title="Favstar.fm asking for email after using Twitter for identity by adewale_oshineye, on Flickr"><img alt="Favstar.fm asking for email after using Twitter for identity" height="184" src="http://farm9.staticflickr.com/8507/8463990561_21f6c1a364.jpg" width="500" /></a></div>
<div class="p2">
<br /></div>
<div class="p1">
Sometimes you have to do things the hard way. Usually it's because you have large numbers of accounts with unverified email addresses (for instance if you used a standard OpenID IDP or used Twitter without capturing and verifying email addresses) or you're migrating users from one IDP to another. </div>
<div class="p2">
<br /></div>
<div class="p1">
In that case you have to provide a 'connect flow.' This is where the user signs-in to your service with one IDP and you ask them to 'connect' with additional IDPs. Afterwards you know that the same person owns that set of accounts even if they have different email addresses associated with them. </div>
<div class="p2">
<br /></div>
<div class="p1">
<a href="http://www.flickr.com/photos/adewale_oshineye/9354119740/" title="Connecting accounts on Soundcloud site by adewale_oshineye, on Flickr"><img alt="Connecting accounts on Soundcloud site" height="122" src="http://farm4.staticflickr.com/3736/9354119740_0108d19e02.jpg" width="500" /></a></div>
<div class="p2">
<br /></div>
<div class="p1">
The heuristics above mean that the NASCAR anti-pattern doesn't have to harm conversion rates or UX.</div>
<br />
<div class="p1">
If you'd like to learn more about this stuff I'll be attending <a href="http://overtheair.org/">Over The Air 2013</a> where I'll be walking people through examples of these heuristics in production and talking about the multi-device multi-platform post-NASCAR future of identity. Join me. </div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-85702378402614783572013-09-18T00:12:00.001+01:002017-05-30T01:04:52.788+01:00Why doesn't this blog allow comments?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="p1">
Should your blog have comments? That's one of the perennial questions that every blogger faces. Are comments a way to bring in vital feedback from the-people-formerly-known-as-the-audience or are they merely a mechanism for enabling strangers to spew hatred and bile on a page with your name attached?<br />
<br /></div>
<div class="p1">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/adewale_oshineye/8600702330/" style="margin-left: 1em; margin-right: 1em;" title="Not now by adewale_oshineye, on Flickr"><img alt="Not now" src="http://farm9.staticflickr.com/8388/8600702330_bd8a910a4c.jpg" height="500" width="375" /></a></div>
<br /></div>
<div class="p1">
Historically my position has been "comments are bad, run away." My reasons included:</div>
<div class="p1">
</div>
<ul style="text-align: left;">
<li>I really don't want to deal with spam. The only thing worse than having spam on your blog is using moderation systems that mean I have to read every spammy comment in order for <i>you</i> to get a better experience. I like you but I don't like you that much.</li>
<li><strike>Buzz</strike>Google+ is a better conversational network than my blog. Every post on my blog ends up on <a href="https://plus.google.com/107025346025182420399/posts">my blog's Google+ Page</a> as well.</li>
<li><strike>Buzz</strike>Google+ also has the advantage that there can be multiple conversations by completely disjoint communities about the same blog post.</li>
<li><strike>Buzz</strike>Google+ emphasises <a href="http://www.meatballwiki.org/wiki/UseRealNames">Real Names</a><span class="s2"><a href="http://www.meatballwiki.org/wiki/UseRealNames"> </a>and <a href="http://meatballwiki.org/wiki/SerialIdentity">Serial Identity</a>. This means I can look at </span>people's activity stream to see what they've been posting about, commenting upon and sharing. Of course, just because you're using your real name doesn't mean that you won't say or do things that I find objectionable but which your community finds laudable.</li>
<li>I agree strongly with Derek Powazek that <a href="http://powazek.com/posts/2463">your right to free speech stops where my territory starts</a>.</li>
<li>I think it's a terrible idea to put everybody who has an opinion on a topic into the same room. That invariably leads to name-calling because they have so little common ground or shared vocabulary. For every person who understands the topic and wants to discuss nuances there'll be 10 people who would like a clearer explanation of the fundamentals. </li>
</ul>
<div class="p1">
All of the above are good and sound reasons for disabling comments. So why have I just enabled comments on this blog?<br />
<br /></div>
<div class="p3">
</div>
<div class="p1">
The main reason is that I have <a href="https://googleblog.blogspot.com/2013/04/bringing-google-comments-to-blogger.html">new technology</a> and I want to see if, just this once, technology can solve a social problem. The secondary reason is that I'm interested in aggregating the conversations around my blog posts. My hope is that this aggregation will help me discover people who are saying interesting and insightful things about what I've written.</div>
<div class="p3">
<br /></div>
<div class="p3">
I could be wrong but I live in hope.<br />
<br />
<a href="http://www.flickr.com/photos/adewale_oshineye/8599605585/" title="Now by adewale_oshineye, on Flickr"><img alt="Now" src="http://farm9.staticflickr.com/8528/8599605585_d0ae69e15e.jpg" height="500" width="375" /></a></div>
<div class="p3">
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-7024962419874058382013-06-19T10:07:00.001+01:002013-06-19T10:07:49.594+01:00In Praise Of Shadows<div dir="ltr" style="text-align: left;" trbidi="on">
I bought <i>In Praise Of Shadows</i> by Junichiro Tanizaki in a Dutch museum. It's an admirable corrective for anyone who feels that their taste has been overwhelmed by any particular aesthetic.<br />
<br />
<a href="http://www.flickr.com/photos/adewale_oshineye/9074414557/" title="In praise of shadows by adewale_oshineye, on Flickr"><img alt="In praise of shadows" height="500" src="http://farm8.staticflickr.com/7400/9074414557_3a8dcdcbf7.jpg" width="375" /></a>
<br />
<div class="p1">
<br />
"a man who has a family and lives in the city cannot turn his back on the necessities of modern life" p3</div>
<div class="p2">
<br /></div>
<div class="p1">
"I always think how different everything would be if we in the Orient had developed our own science" p13</div>
<div class="p2">
<br /></div>
<div class="p1">
"how much better our own photographic technology might have suited our complexion, our facial features, our climate, our land" p16-17</div>
<div class="p2">
<br /></div>
<div class="p1">
"Of course this 'sheen of antiquity' of which we hear so much is in fact the glow of grime. In both Chinese and Japanese the words denoting this glow describe a polish that comes of being touched over and over again, a sheen produced by long years of handling--which is to say grime." p20</div>
<div class="p2">
<br /></div>
<div class="p1">
"elegance is frigid" p20</div>
<div class="p2">
<br /></div>
<div class="p1">
"Sometimes a superb piece of black lacquerware, decorated perhaps with flecks of silver and gold -- a box or a desk or a set of shelves -- will seem to me unsettling garish and altogether vulgar. But render pitch the void in which they stand, and light them not with the rays of the sun or electricity but rather a single lantern or candler: suddenly those garish objects turn somber, refined, dignified. Artisans of old, when they finished their works in lacquer and decorated them in sparkling patterns, must surely have had in mind dark rooms and sought to turn to good effect what feeble light there was." p23</div>
<div class="p2">
<br /></div>
<div class="p1">
"The quality that we call beauty, however, must always grow from the realities of life, and our ancestors, forced to live in dark rooms, presently came to discover beauty in shadows, ultimately to guide shadows towards beauty's end." p29</div>
<div class="p2">
<br /></div>
<div class="p1">
"For the painting here is nothing more than another delicate surface upon which the faint, frail light can play; it performs precisely the same function as the sand-textured wall." p32</div>
<div class="p2">
<br /></div>
<div class="p1">
"This was the genius of our ancestors, that by cutting off the light from this empty space they imparted to the world of shadows that formed there a quality of mystery and depth superior to that of any wall painting or ornament. The technique seems simple, but was by no means simply achieved." p33</div>
<div class="p2">
<br /></div>
<div class="p1">
"And there may be some who argue that if beauty has to hide its weak points in the dark it is not beauty at all" p46</div>
<div class="p2">
<br /></div>
<div class="p1">
"we find beauty not in the thing itself but in the pattern of shadows, the light and the darkness, that one thing against another creates." p46</div>
<div class="p2">
<br /></div>
<div class="p1">
"A phosphorescent jewel gives off its glow and color in the dark and loses its beauty in the light of day. Were it not for shadows, there would be no beauty." p46</div>
<div class="p2">
<br /></div>
<div class="p1">
"It struck me that old people everywhere have much the same complaints. The older we get the more we seem to think that everything was better in the past. Old people a century ago wanted to go back two centuries, and two centuries ago they wished it were three centuries earlier. Never has there been an age that people have been satisfied with." p59</div>
<div class="p2">
<br /></div>
<div class="p1">
"I would call back at least for literature this world of shadows we are losing. In the mansion called literature I would have the eaves deep and the walls dark, I would push back into the shadows the things that come forward too clearly, I would strip away the useless decoration. I do not ask this be done everywhere, but perhaps we may be allowed at least one mansion where we can turn off the electric lights and see what it is like without them." p64</div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.comtag:blogger.com,1999:blog-3804478417938445896.post-81038187916464215312013-04-08T20:09:00.000+01:002013-09-18T10:45:12.581+01:00Open always wins?<div dir="ltr" style="text-align: left;" trbidi="on">
"Open" is one of my tribe's <a href="http://www.chakoteya.net/startrek/54.htm">worship words</a>. It is a word that is beyond criticism, analysis or critique except from <a href="http://en.wikipedia.org/wiki/Evgeny_Morozov">professional troll</a>s.<br />
<div class="p2">
<br /></div>
<div class="p1">
So what does it mean when people say "open always wins?" It means that because TCP/IP, HTML and Apache won then open systems, <a href="http://en.wikipedia.org/wiki/Open_standard#Examples_of_open_standards">open standards</a> and open source will always win given a long enough timeline. If the open solution isn't winning yet then we just have to wait.</div>
<div class="p2">
<br /></div>
<div class="p1">
This may seem like a strawman but Chris Saad bluntly stated "<span class="s2"><a href="http://blog.areyoupayingattention.com/2012/02/the-open-web-is-dead-long-live-the-open-web/">Whether it’s a year, a decade or a century, Open. Always. Wins.</a>"</span></div>
<div class="p2">
<br /></div>
<div class="p1">
I disagree. Mere openness isn't enough. Just because your product or service is open doesn't mean it's destined to win. Plenty of open solutions have 'lost' but we tiptoe past <a href="http://en.wikipedia.org/wiki/Information_Rules">that particular graveyard</a>. We either pretend that we don't remember its denizens or that they're merely sleeping.</div>
<div class="p2">
<br /></div>
<div class="p3">
Whilst I have a religious belief in openness and standards I can see the difference between what I want to be true ("open always wins" and "next year will the year of Linux on the desktop") and what is actually true. I want open systems to win but I'm also aware that this isn't guaranteed.</div>
<div class="p2">
<br /></div>
<div class="p1">
In fact when open solutions win it's because they:</div>
<ul class="ul1">
<li class="li1">have superior User Experience</li>
<li class="li1">have superior <a href="http://blog.oshineye.com/2011/05/what-is-devexp.html">Developer Experience</a></li>
<li class="li1">give each user/developer/company <a href="http://blog.oshineye.com/2012/12/the-other-side-of-creating-more-value.html">more value</a> than the equivalent closed solution</li>
<li class="li1">create a larger (and thus more valuable) market/network than the equivalent closed solution</li>
<li class="li1">co-opted the existing closed solutions</li>
<li class="li1">do something that no closed solution can match</li>
<li class="li1">commodify existing closed solutions thus rendering them unprofitable</li>
</ul>
<div class="p2">
<br /></div>
<div class="p1">
<span class="s3">Despite this </span>I'm always surprised by the number of people who believe that openness is a sufficient condition for success.<span class="s3"> I'd even go so far as to </span>suggest that if the only quality a solution has is its openness then that's a good indicator it's going to fail.<br />
<br />
<a href="http://www.flickr.com/photos/adewale_oshineye/8600712812/" title="Open by adewale_oshineye, on Flickr"><img alt="Open" height="500" src="http://farm9.staticflickr.com/8523/8600712812_88eed53281.jpg" width="375" /></a></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-13557706690928792962013-03-31T08:38:00.000+01:002013-03-31T08:40:11.544+01:00Speakerconf 2013<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="http://www.flickr.com/photos/adewale_oshineye/8559547528/" title="A man, a hat, ... by adewale_oshineye, on Flickr"><img src="http://farm9.staticflickr.com/8085/8559547528_687dd72c7d.jpg" width="500" height="333" alt="A man, a hat, ..."></a>
What is Speakerconf? Speakerconf is a small (roughly 16 attendees) invite-only conference where everybody who attends gives a presentation about a topic that's currently on their mind.<br />
<br />
Speakerconf 2013 was educational, fun and humbling--all at the same time. It featured a wide range of speakers talking about a wide range of topics. Everything from UX to <a href="https://github.com/clojure/core.logic">constraint programming</a> to microservices to model checking to tail-call optimisation in Java 8 got covered.<br />
<br />
The breadth and sophistication of the talks means that in every session at least some us were completely befuddled whilst others were making connections across disciplines that don't normally share the same conference let alone the same room. For every talk about <a href="http://en.wikipedia.org/wiki/Computation_tree_logic">computation tree logic</a> that went completely over my head there was a moment when I got to introduce people to the ideas in <a href="http://www.lexifi.com/files/resources/MLFiPaper.pdf">composing contracts </a>or <a href="http://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/">As We May Think</a>. Many of the other attendees told me they had a similar experience. This resulted in an environment that was unusually conducive to respectful and enlightening conversation.<br />
<br />
If you get invited to attend a Speakerconf then I strongly recommend you accept.<br />
<br />
<object width="400" height="300"> <param name="flashvars" value="offsite=true&lang=en-us&page_show_url=%2Fphotos%2Fadewale_oshineye%2Fsets%2F72157633001036374%2Fshow%2F&page_show_back_url=%2Fphotos%2Fadewale_oshineye%2Fsets%2F72157633001036374%2F&set_id=72157633001036374&jump_to="></param> <param name="movie" value="http://www.flickr.com/apps/slideshow/show.swf?v=124984"></param> <param name="allowFullScreen" value="true"></param><embed type="application/x-shockwave-flash" src="http://www.flickr.com/apps/slideshow/show.swf?v=124984" allowFullScreen="true" flashvars="offsite=true&lang=en-us&page_show_url=%2Fphotos%2Fadewale_oshineye%2Fsets%2F72157633001036374%2Fshow%2F&page_show_back_url=%2Fphotos%2Fadewale_oshineye%2Fsets%2F72157633001036374%2F&set_id=72157633001036374&jump_to=" width="400" height="300"></embed></object>
<br /></div>Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.comtag:blogger.com,1999:blog-3804478417938445896.post-91110252381575437542013-03-20T15:20:00.003+00:002013-09-18T10:48:03.874+01:00Why do we bother with APIs?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="p1">
<a href="http://www.flickr.com/photos/adewale_oshineye/7326760044/" title="I love APIs by adewale_oshineye, on Flickr"><img alt="I love APIs" height="375" src="http://farm9.staticflickr.com/8146/7326760044_f78b9c97e3.jpg" width="500" /></a><br />
Sometimes people wonder why we bother building APIs since it seems they can end up being used in ways that compete with our own products.</div>
<div class="p2">
<br /></div>
<div class="p1">
There are idealistic reasons for building APIs, <a href="http://googleblog.blogspot.de/2009/12/meaning-of-open.html">as outlined by Jonathan Rosenberg</a>, but there are also commercial benefits even if you don't share that philosophy. The main one is that APIs reduce the friction involved in making your services more valuable. They make it easier for other people to add data to your services. </div>
<div class="p1">
<br />
They also attract more users to your services by effectively advertising them on other people's sites. As well as increasing your visibility APIs also ensure that users are more likely to try your services since the risk of lock-in is reduced. If you have at least a CRUD API potential users know that there will be a mechanism for extracting their data if something better comes along or if your services change in ways they don't like.<br />
<br />
The other benefit of APIs is that they lower the cost of experimentation and increase the set of potential experimenters. These experiments can serve your users in two ways. Firstly they can handle niche use cases without cluttering the user interface of the application. Secondly some of these niche use cases may turn out, after a period of refinement, to be useful for mainstream users or for attracting completely new sets of users.</div>
<div class="p2">
<br /></div>
<div class="p1">
Another thing we've learned the hard way is that if you don't give people an API or you give them an insufficient API they'll resort to screen-scraping and hacking in order to unlock the value in your product. This can create <a href="https://plus.google.com/106413090159067280619/posts/HRpPyB27KSU">dependencies on things that were never meant to be stable</a> or it can lead to the emergence of <a href="https://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI">widely-used but unofficial APIs</a>. </div>
<div class="p1">
<br /></div>
<div class="p1">
That behaviour can harm your product, your developers and your users. For example it can lead to a mismatch in expectations when some developers believe they're using an official API with established deprecation and change management policies. You also have to ensure that the APIs you create don't damage the product, for instance, by making it very easy to spam or game your system.</div>
<div class="p2">
<br /></div>
<div class="p1">
Providing an API, <a href="http://blog.oshineye.com/2011/05/what-is-devexp.html">no matter how good</a>, is just the start. The next challenge is to make something valuable enough that developers will use it in the absence of some extrinsic compulsion.</div>
<div class="p2">
<br /></div>
<div class="p1">
Firstly this involves making something that's easy to experiment with. So it should be easy to copy-paste a personalised URL into a browser and see a pretty-printed dataset.</div>
<div class="p2">
<br /></div>
<div class="p1">
Then you have to offer a path from there. The path starts with letting people play even if they don't understand your service all the way to the point where they understand your abstractions and the specifications you're using.</div>
<div class="p2">
<br /></div>
<div class="p1">
People should be able to go from playing in the browser to playing at a terminal with curl/wget to playing with an OAuth-enabled HTTP client to playing with your specialized wrapper libraries for your API to building businesses upon your platform.</div>
<div class="p2">
<br /></div>
<div class="p1">
But you can't just stop there. If you want to go from merely offering an API (typically a set of CRUD operations on your product's datasets) to <a href="http://www.hunterwalk.com/2012/01/you-dont-get-to-decide-if-youre.html">building a viable platform</a> you need to solve some difficult problems:</div>
<div class="p1">
<br />
<ul style="text-align: left;">
<li>how does your platform, as opposed to your product, generate revenue or value for you?</li>
<li>how does your platform generate revenue or value for those who build upon it?</li>
<li>how do you respond to and/or incorporate the innovations that will be built upon your platform?</li>
<li>how do you nudge developers into creating more value than they capture from your users and your platform?</li>
<li>what happens to this <a href="http://blog.oshineye.com/2012/12/the-other-side-of-creating-more-value.html">surplus value</a>? Is it being re-invested in the platform or siphoned off?</li>
</ul>
</div>
<div class="p2">
Even if you solve all these problems you don't have any guarantees of long-term success. The transition from API to platform to ecosystem is difficult and most APIs don't make it. However APIs can still help developers create new possibilities along the way.</div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0tag:blogger.com,1999:blog-3804478417938445896.post-12801449895804089462013-03-19T18:39:00.000+00:002013-09-18T11:08:08.078+01:00What do you mean 'we'?<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="p1">
"The Moving Finger writes; and, having writ,</div>
<div class="p1">
Moves on: nor all thy Piety nor Wit</div>
<div class="p1">
Shall lure it back to cancel half a Line,</div>
<div class="p1">
Nor all thy Tears wash out a Word of it."</div>
<div class="p1">
-- <a href="http://en.wikipedia.org/wiki/Rubaiyat_of_Omar_Khayyam">http://en.wikipedia.org/wiki/Rubaiyat_of_Omar_Khayyam</a></div>
<div class="p1">
<br /></div>
<div class="p1">
</div>
<div class="p1">
The web that Anil Dash wrote about wasn't lost. It was rejected. </div>
<div class="p2">
<br /></div>
<div class="p1">
Dash himself rejects it when he uses a commenting system that only allows Facebook users to comment. Daniel Tunkelang rejected it when he <a href="http://thenoisychannel.com/2013/03/07/the-noisy-channel-has-moved-to-linkedin/">abandoned his blog</a> in favour of a network that gives him higher levels of engagement. I reject it when I use Instagram to take and share photos just because it's more convenient than the alternatives. </div>
<div class="p2">
<br /></div>
<div class="p1">
My initial response to Anil Dash's <a href="http://dashes.com/anil/2012/12/the-web-we-lost.html">The Web We Lost</a> was a mixture of amusement at his rose-tinted nostalgia, annoyance at his revisionist history and bemusement at his usage of Facebook comments. As time has gone on I've realised that Dash is not a hypocritical finger-wagging <a href="http://en.wikipedia.org/wiki/Reactionary">reactionary</a> but just another sensible person making sensible decisions about the networks that will generate the most engagement for his content. Of course these sensible decisions happen to clash with his stated beliefs.</div>
<div class="p2">
<br /></div>
<div class="p1">
The mainstream of humanity actively rejected the web-that-was rather than accidentally let it slip away. They rejected it for much the same reasons they rejected the prospect of running their own power generator. It turns out that using a central power grid gives you a better quality service for less effort which frees you to focus on the things you really care about. Humanity rejected a vision of the web where everybody runs their own websites because it turned out that most people don't care as much about maintaining infrastructure as the geeks who formed the majority of the web's users 10 to 20 years ago. That's why every time I see someone, for instance <a href="http://www.flickr.com/photos/adewale_oshineye/8306256102">Clay Shirky, who has been cheerfully running a compromised blogging engine on his own domain for years</a> I shudder at the idea that we once thought self-hosting was going to be the norm.</div>
<div class="p2">
<br /></div>
<div class="p1">
<a href="http://blogs.reuters.com/felix-salmon/2012/12/18/how-capitalism-breaks-the-web/">Felix Salmon's article</a> was one of the first responses that acknowledged this problem. It made me realise why Dash's article reminded me so much of <a href="http://weeklysift.com/2012/09/10/the-distress-of-the-privileged/">the distress of the privileged</a>. That's because the 'we' who lost something is the set of middle-aged geeks who miss the way things used to be and want to roll back time to a world where only geeks could harness the power of the web. Like scribes bemoaning the advent of universal literacy the comments section of Dash's post is full of people saying how much better things were when communication tools were difficult to use and restricted to a sophisticated elite.</div>
<div class="p2">
<br /></div>
<div class="p1">
This makes me sad. The <a href="http://trenchant.org/daily/2012/12/14/">dream of the early web</a> was that by removing the <a href="http://www.ftrain.com/wwic.html">Gutenbourgeois</a> as gatekeepers we would create the possibility for new voices to be heard. Wish granted. </div>
<div class="p2">
<br /></div>
<div class="p1">
Unfortunately the technocratic response to these new voices was to dismiss them as an <a href="http://en.wikipedia.org/wiki/Eternal_September">Eternal September</a> of clueless newbies. It's as if the web was better before all these 'other' people turned up and started making choices 'we' don't like. It's as if all those developers choosing to build upon technologies with clear value propositions (build upon this platform and you'll get users and paying customers) and good <a href="http://blog.oshineye.com/2011/05/what-is-devexp.html">DX</a> were wrong. It's as if the billions of non-geeks were either ignorant, misled or suffering from false consciousness when they chose closed systems with great UX.</div>
<div class="p2">
<br /></div>
<div class="p1">
Robin Sloan has a refreshing perspective on this issue. He writes, on Medium, that we've reached a point where our taste has outpaced our skill. Our taste means we demand that an acceptable website must have lots of qualities that are beyond the skill of the average individual. By framing the issue in terms of taste and skill he shows why the pendulum is unlikely to swing back. Running a sufficiently high quality web site, as opposed to a web presence, is so hard that the amateur web looks like <a href="https://plus.google.com/+AdeOshineye/posts/6ch8Kh4Ga3n">a wasteland of dead blogs, unmaintained websites and broken links</a>. <a href="http://identi.ca/anildash">Again</a> and <a href="https://alpha.app.net/anildash">again</a> and <a href="https://joindiaspora.com/people/9b090433c243e940">again</a> sensible people choose better UX or a larger network over a more open, decentralised or federated service. But what if this flight to quality isn't a problem?</div>
<div class="p2">
<br /></div>
<div class="p1">
What if all those billions of people made intelligent decisions that made sense for them? What if the people saying that the past was better than the future are the ones who are wrong? What if we reject this mythical past in favour of a new future where we try to build new things that people use because they're <a href="http://blog.oshineye.com/2012/12/the-other-side-of-creating-more-value.html">better solutions</a> not because they claim superior morality?</div>
<div class="p2">
<br /></div>
<div class="p1">
Appeals to a bygone era where the web was more open but less diverse aren't going to inspire the construction of a better future as history teaches us that "<a href="http://www.fistfulayen.com/blog/2007/10/convenience-wins-hubris-loses-a-presentation-for-some-music-industry-friends/">convenience wins, hubris loses</a>." Instead those appeals sound like the beleaguered art critic moaning that "<a href="http://www.guardian.co.uk/commentisfree/2012/dec/19/instagram-collective-act-self-delusion">taking a picture feels like signing up to some mad collective self-delusion that we are all artists with an eye for beauty, when the tragicomic truth is that the sheer plenitude and repetition of modern amateur photography makes beauty glib</a>." When Dash writes that there's "<a href="http://dashes.com/anil/2012/12/rebuilding-the-web-we-lost.html">an entire generation of users who don't realize how much more innovative and meaningful their experience could be</a>" but can't point to any examples it sounds like yet another hollow claim that things were better when we were young.<br />
<br />
Maybe things really were better when we were young but I've learned to distrust appeals to bygone golden ages. Instead I want to hear people talking about vibrant futures. I want to see people working on new ideas that may not work out but which open up new possibilities. I want to see new people making new things. I want to see people making new things with all the uncertainty and doubt that brings.<br />
<br />
This is why I'm increasingly hopeful about efforts like <a href="http://indiewebcamp.com/Main_Page">IndieWebCamp</a> and <a href="http://straup.github.com/parallel-flickr/">ParallelFlickr</a>. These are people building things that are useful primarily for themselves and possibly for others. That's how we'll invent a new and better web.<br />
<br />
<a href="http://www.flickr.com/photos/adewale_oshineye/5820371251/" title="Jaiku forever by adewale_oshineye, on Flickr"><img alt="Jaiku forever" height="374" src="http://farm3.staticflickr.com/2389/5820371251_2189085618.jpg" width="500" /></a>
</div>
<br />
<div class="p1">
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/01477786395327086892noreply@blogger.com0