• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Archives for October 2019

Slicing through the Web with seamless Portals

October 22, 2019

On native devices, I find myself naturally following the pattern of:

  • home screen
  • launch app
  • back to home screen
  • launch app
  • repeat

Sure, there are times in which I will bounce from app to app, but it often feels heavy, and most of the time it is an app showing some Web content.

On the Web this happens too (new tabs), but I really feel like I am surfing the Web when I am flowing through experiences…. tap to tap to tap. This can allow me to get a task done across multiple services in an enjoyable way.

You can also feel this when you see experiences that compose together. We get this naturally through SDKs that will embed on pages, which may use iframes or direct embedding. I remember the mashup generation, where there was an explosion of wiring things together. I loved playing with Yahoo! Pipes in this vein too, and feel like composable blocks can enable a lot of innovation.

However, the “C” in SLICE deserves more love. The flowing nature of the Web, and the way that pieces can be entwined is pretty special. It is what makes it feel like a real Web after all vs. a series of domains with launches as the entry point to them all.

This connectivity, sometimes loosely coupled where sites can be embedding or linking to you without you having to know, and sometime explicitly coordinated between a couple parties, gives us our commons.

Alex Russell (@slightlylate) stood on our stage exactly 2 weeks ago and gave a wakeup call about the state of the mobile web. He explains what we must do to help the web succeed on mobile.https://t.co/8OoAywu3iP

— Fronteers Conference (@FronteersConf) October 18, 2019

One of the reasons that Alex Russell speaks so strongly on the performance of the Web is because of this commons and how we effect each other. Every time a user interacts with a web site it ticks some state on how they feel about the overall experience of the Web. As you surf through three connected sites, if the second one is really slow, what is the impact? How much does it matter than the other two were instant? This is subtly different to the general bar on a platform based on the quality of the individual experiences.

If there is a huge variety in interactions, will will be more likely to see more composition? I already feel like I used to browse around more, and we had classics such as web rings that are the perfect example of one site flinging you on to the next, building momentum. Now it feels like the motos operandi is often “keep users in my experience!” which I know is particularly due to dominant monetization models. This gets me thinking about attribution systems baked in that would incent links out again.

The Empty, White Page

The other side of the user experience, is the advent of the SPA. While it is hard to load it up without causing a huge initial load, once up and running, you the developer have full control over routing and navigating throughout your experience.

Stuart Langridge gave a great talk on this that is typically entertaining to boot. He talks about one of the key problems with flowing between experiences, in that we tend to break the linkage with a bright white empty screen when going between domains.

This is like being blinded as you surf, and makes you feel disconnected as you navigate.

What if we could setup lovely hand-offs between navigations? What if you could use these across your own site or set of sites without being forced into an SPA architecture or PJAX is just on your own?

This is why I am excited about Portals. We finally have a way that will fix up the seams in interesting overlapping ways. Each side of the navigation can talk to each other, enabling a lot of new innovation again in how your surf.

Finally, you can get fantastic UX, with a very loosely coupled architecture and codebase. This is huge, especially for large teams. We have built up so much machinery in the name of allowing a massive site with teams for each of /product, /checkout, /search, bundle, build, and ship separately. Or across subdomains, or different sites in a shared portfolio.

This is why I am excited on having us work together to build out Portals and I hope you have a play and give the community feedback. And partnered with web packaging, you can be flowing through the Web like Spiderman through Metropolis consuming packages from a close by CDN.

We are always building out capabilities to help you get the most from the native platforms your users are on, but I *really* love thinking about what makes the Web special and different, and I think there is so much more that be done through this notion of the Web and composition.

The difference between Platforms and Ecosystems

October 7, 2019

tl;dr: “What’s the difference between a platform and an ecosystem?” This simple question resulted in an ecosystem strategy to connect sub-ecosystems that work on the Web. What if we lean in and deeply connect our tools, services, frameworks, and platforms….. and align on the right incentives for a healthy web?

I work in a product area of Google that is called Platforms and Ecosystems, and I sometimes reflect on the question “what’s the difference between a platform and an ecosystem?”

There are many, but I have found myself diving into the differences in complexity of a rich ecosystem.

With platforms we often think in layers, each layer building on each other, and the interfaces mostly being at the boundaries. This is a nice abstraction when done right, as it isn’t leaking all over the place.

The layers view of a platform

An ecosystem often forms on top of a platform, or if it gets connected enough, you get combinations. Sub-ecosystems form that have their own fractal view of the world, and they may connect with multiple technical platforms (e.g. the React ecosystem touching Web, iOS, Android, Desktop, ….).

The Web is complex enough that it is one of the canonical examples of an ecosystem that has many sub-ecosystems. You can even slice “the web” itself into pieces including the technical client platform that is embedded in almost every native platform there is (WebView anyone?) as well as the connected open Web, where many technical stacks are available to run as well.

A week ago, I had the pleasure of spending some time with representatives from major global CMSes, and they are a fantastic example of sub-ecosystems.

We spoke of ecosystem loops, and how an ecosystem has so many more connection points that are not restricted to layers, and are multi-directional.

These connection points, when strong, can enable a healthy web ecosystem. This realization has changed the way that we work, thinking about we can truly enable healthy connections.

Foundationally, we obviously want to build web platform APIs that work for as many ecosystems as possible, whilst also push the web. We also work to build clear guidance on web.dev that helps developers understand what is possible on the web across key pillars and principles. We want to deliver new and better tools that help you create, debug, and deliver actionable insights to you (e.g. DevTools, Lighthouse, CrUX).

Speak the right language

Lighthouse Stack Packs can speak your language

One of the problems we see, is that there is often an impedance mismatch between the layer of abstraction that a developer uses (e.g. using a particular framework, set of libraries, or backend infra) and the feedback that tools and services surface.

We are on a journey across our portfolio to fix this, and the best example is probably Lighthouse:

  • Lighthouse plugins allow you to build on the platform to offer your own audits and rulesets, enabling you to enforce you own criteria or requirements. For example, a framework may have important linting tests, or an ecommerce platform may have retail oriented audits.
  • Lighthouse Stackpacks bring an understanding of the ecosystem into the existing core rules. Don’t give generic guidance on next generation images when you could give custom guidance for particular plugins or point the developer to a setting in the admin console.

Elsewhere we are thinking of similar evolutions:

  • web.dev offers framework specific guidance, but what if the base guidance changed based on your needs?
  • There are many Chrome extensions for developers which extend DevTools, but what if there was a strong plugin API where knowledge can be brought to the core tools?

I am excited to work with the ecosystem to enable this kind of intelligence for our collective developers.

Show me the incentives!

We can make life much better for developers, but we have also learned that this isn’t enough to fully elevate the web together.

We want to see the flywheel moving nicely on the above ecosystem loops, with users engaging with high quality content from developers and their sites and platforms.

As platforms, how do we enable this outcome? It’s hard, but we have learned a lot from the work that the ecosystem did to move to HTTPS.

Moar TLS!

It may be hard to think back to the days when HTTPS wasn’t the norm, and only 30% of traffic was secured. How could we make it the vast majority? I remember hearing thought such as: “it can’t be done!”, “people just don’t actually care enough!”, “it’s too hard!”

In retrospect, it’s interesting to reflect on the parts and pieces that I think collectively drove things forward:

#1 Knowledge and Insights
There was a lot of content on *why* this is important, and *how* to do it. I remember it being really quite hard to do, and also waking up in a sweat on a couple of occasions with my brain racing: “did my certificate expire?“

#2 Tooling
The ecosystem jumped in to help make it MUCH easier. LetsEncrypt changed the game, and servers and hosts jumped in too.

#3 Demand
Now it’s easier, and it’s the right thing to do, but companies have huge backlogs. How do we make “the right thing to do” blindingly aligned to users and the company?

We need the right incentives, and this was the final puzzle piece. How do we reward developers that do the right thing? Some examples here are:

  • Browser UI surfacing quality: At first browsers changed their UI to highlight the good (e.g. showcase “secure”), and then…. over time…. deliberately…. switch to the point where the default is secure and we highlight the insecure
  • HTTPS required for API usage: WIth Service Workers, and powerful capabilities such as those being worked on via Project Fugu we need to make sure that we aren’t setting users up for attacks. This keeps our users secure, and also incentivizes developers to move to HTTPS to gain access to said APIs.
  • Acquisition: highly quality content is better for our users, so we want to make sure that Google Search is driving engagement to that content. When HTTP was added as a ranking factor we noticed an increase in adoption.
    It has been great to see the sum of the parts add up to the great adoption of HTTPS and we continue to push.

Moar Incentives!

How do we learn from HTTPS and bring this to the other areas of quality such as performance?

We will make sure that:

  • We will be clear about the metrics that we think represent quality
  • We will surface data and insights for developers and decision makers across our suite of products, and accessible for third party tooling solutions
  • We are very deliberate in carrots and sticks so everyone has time to plan
  • We will work with the sub-ecosystems so we can align on everything above so we row in the same direction. For example, if you are an established CMS provider, it isn’t solely important to track how many themes and plugins you have in your marketplace, but also note the quality of the output and how you can use said marketplace to share the same incentives (surfacing the right metrics etc).

How can we build connections that will strengthen us all? Do you see anything we should be doing? I am all ears.

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...