Almaer.com Reopens For Business

As the Web turns 30, I reflected on what made, and makes, it different and great, and this lead me to thinking about when Medium started. I really appreciated the approach-ability of the user experience, how it helps authors focus on content, and also helped people find an audience.

There was an option of hosting your medium content on your own domain, but that went away, which was the first moment I thought about bringing my content back to my own site.
As I see the simple clean article experience become one of pop-ups and up-sells and web vs. app differences, it was finally time to make the switch, and thus I am posting on blog.almaer.com as the canonical location, and will syndicate on Medium and elsewhere as appropriate.

It is shocking that it took me this long, to be honest, as your own domain is something quite special on the Web and Internet. For publishers, who aren’t just writing as a hobby as I do, it is a business model decision.

Although it obvious differs for different companies, I tend to be the biggest fan of the approach where:

  • By regularly creating great content, your loyal customers will subscribe directly, as they are investing not just in a one off article, but rather invest in future reporting.
  • Any time you syndicate content, you are using it as customer acquisition into the subscription business, and can of course monetize through advertising.

You have to go into this knowing that users may be trusting the aggregator and giving them subscription as the source for great future content.

Restaurants vs. Food Delivery

I liken this a little to restaurants and food delivery. If a punter comes to your restaurant, you own the entire experience. You are best set to make it great and build a loyal customer that you may even know by name over time.

If you have excess supply, maybe you want to be on DoorDash/Caviar/UberEats etc. These customers are browsing and may not feel like going out, and you have a chance to experience your wares. If you believe in the quality of your food, maybe they will be impressed and will want to come in. You don’t control the experience in the same way, and these customers may not be the type that wants to go to you directly, no matter the quality, so it is also important to acknowledge that (and how much you can make from the food itself…. akin to the ads). Maybe you make enough from the transactions that the extra reach is fully worth it. The restaurant could even become a showroom of sorts….. but this is a dangerous position to be in. How sticky are these diners to you?

Your own home on the Web, with your own domain, is your restaurant. Your loyal users want to hang out there with you. Those are the users that would like a high quality PWA. You can think through how to drive traffic to you, or how to get value from your content living in other experiences, but it feels good to see more people starting to really think about this…. and it was certainly time for me to make the switch, even for my lil old blog.

Becoming a better Pacesetter for Web Developers in 2019

Roger Bannister breaking the 4 minute mile barrier

When you work on a platform, you quickly feel how you are one part of the overall ecosystem. The Web is a huge ecosystem with diversity galore. Web standards, multiple browsers, a huge number and variety of devices, a plethora of tools and services available. It can be quite overwhelming at times!

Over the holiday break, I was naturally noodling on our role, and how to help improve the Web. As is cliche for this time of year, I jumped aggressively into the desire for healthy habits, and went on (short!) daily runs, often with my dog, or 9 year old son. When running with Josh, I started to think about the role of a Pacesetter:

“A runner who leads a distance running event to ensure a fast time and avoid excessive tactical racing.”

I want 2019 to be a year in which we will run to where the Web community is today, and do all we can to train to get in shape for where we all need to be.

We want developers to be successful on the Web by shipping great experiences for our (collective) users. Part of this success revolves around us setting up the environment (the meet) to have as many users available as possible, setting up the rules of the game, and helping developers train and get better.

The Goldilocks Pacesetter

What does it take to be a good pacesetter? You need to make sure that you aren’t on either end of these extremes:

  • If you are too far ahead of the runner then you are no longer making pace for them. They can’t reasonably keep up, and thus you may as well not exist and they will go back to their natural pace.
  • If you are running alongside them, even cheering them along as you do so, you are also not doing your job, and they won’t improve as much as they could.
  • If you win the race you are not doing your job, you need the runners to trust that you are going to do the job you agreed: to make the race fast and competitive and let the racers race.

We need a balance, pushing the pace in a way that is achievable, yet naturally will contain stress (in a good “the only way to improve” way).

How are we reaching developers where they are today?

At Chrome Dev Summit, we shared how we understand that we partner with frameworks, to deliver the surface area that developers use to program for the Web, and how we want to work closely with them:

  1. Include frameworks in the Chrome Intent to Implement process
  2. $200,000 of funding for improving performance best practices in frameworks.
  3. Increased collaboration with frameworks from the Chrome team.

We also know that we need bring the APIs that you need, to make the Web more capable, allowing you to bring your best experiences to the Web. This also includes enhancements to the UI toolkit of the Web, allowing you to build rich, fluid, UI.

We all know there is work to be done there, but we also have more tools available to deliver high quality UIs than ever before. The stack is changing. Salesforce posted on the change they have seen between 2014 and today, and how it enables them to take a very different approach using Web Components. This standard, shared API, gives us interoperability across frameworks. They can invest in fast, accessible, <killer-components>, that work with all. These components could even progressively change under the hood, allowing features such as various Worklets, and a scheduler to improve the experience.

Where do we need to be?

If we work together, we can break the four minute mile equivalent for the Web, which is delivering an instant, responsive, jank-free experience for our users.

There are many types of Web applications, with a variety of trade offs. A tool such as Squoosh is a different beast compared to a content site, or an e-commerce store. We want to deliver a platform that can work well for the variety of use cases we see on the Web, and collectively learn from each other on patterns to build such experiences.

Now we have a challenging goal, it’s time to jump into the New Year, and put in the work to achieve it!


p.s. As always, I am always very interested to hear your thoughts on what you need from the Web platform and ecosystem, and what you would want from a Pacesetter!

It’s time the Web did some Undergrounding


I live in a simple neighborhood in Palo Alto, California. My street is fortunate to have some nice old trees. We have small houses that the wealthy are slowly purchasing, tearing down, and then filling up the entire lot with house. From most vantage points it looks quaint, but then you get the wrong angle, or you go into someones back yard, and an ugly face is shown: a hodge podge of cables and wires are strung up from old pole to old pole.

I have asked neighbors why this is still the case, and I hear a variety of stories. Some believe that everyone has to come together to pay the city to underground this all, and no one has been able to get everyone on board. A hefty storm that knocks out power, or god forbid… Internet, will surely be the trick? Nope. It’s been long enough that surely it’s time to underground this infrastructure.

This is how I feel about the Web right now

We have had many successful undergrounding stories in the Web’s history. That is somewhat obvious, as the mere act of standardization is a key part of the process. It is long known that innovation in new and rapidly changing areas isn’t for the standards process (see Alex Russell’s amazing series on how that world works best). It’s too hard to “get it right, first time”, so basic risk management would suggest that you allow innovation to happen in a few branches and once you have enough data to suggest a decent (you don’t need to fall for the nirvana fallacy!) path, get enough consensus to drive the implementations that beget a true standard.

We see innovation happening all around us. Sometimes we look to other platforms to learn from (e.g. looking at iOS and Android to give us solid clues for how to bring mobile capabilities to the Web), and one other strong source is user space and the Web community. How are web developers solving their problems with various libraries and frameworks? In fact, as we push more capabilities into the platform, allowing a more Extensible Web, we should see even more of an ability for experiments in user land.

If we don’t come around and look for areas where we can take the experimentation and bake it into the platform, we will fail users when it comes to performance and the potential for richer user experiences.

Why will we fail?

The Web is an amazing streaming platform that allows for ephemeral applications that can be controlled, to a large degree, on the server. This is incredibly powerful, and we shouldn’t lose sight of this massive benefit.

However, a trade off like this doesn’t come with zero cost, and we should look at how to balance any cost. We have been doing some of this with stronger caching primitives, service workers, etc. That’s great, but until we can contort the law’s of physics, it will be true that shipping capabilities comes with a large cost. In an ideal world, a website that delivers a shopping experience for users will only send down capabilities tied strongly to said experience. It is less than ideal to also send down large infrastructure (affecting both load and runtime).

When we standardize and put something into the Web platform itself, we get the benefit of a shared core that user space can progressively rely on, and we are able to use a couple more tools as we do so. The platform in the browser has access to the native platform below it, in a way that you just don’t have working on top of the standard Web.

We see the benefits time and time again. With recent Observers, we can get away from the jank-ridden experiences that we have all felt from being on websites that take over scrolling and try to be too clever.

One of the largest undergrounding projects of late has been taking the great ideas in jQuery and bringing them to the platform via querySelector(s), fetch, classList and more. jQuery itself learned from the likes of Prototype, MooTools, Dojo, and others, and offered a slightly different approach. As we in turn learn from this corpus, it is important to realize that we didn’t just “take jQuery and bake it in”. We are often asked to do this, and it’s alluring. I instigated the Google Ajax CDN project back in the day, to answer “can we just cache things so we aren’t downloading the same darn APIs all day long?”

Caching is good, but it isn’t enough. There are tactical issues (how developers bundle, versioning) but there is also the fact that you need to do things differently when you bake something in.

Looking at cabling in my neighborhood again, when a city does this, they don’t just take the same cables and dig a quick hole to shove them in. Once those cables are underground you have new constraints. It’s hard to get to them when something goes wrong, so you want to protect them in a more rigorous manner. The same is true when you standardize something in the Web, as once it’s there you will be maintaining it for ~forever. You can learn, add the new constraints, as well as the new capabilities that the core platform gives you…. and the outcome should be *better* than before.

Ok, so what should we underground?

The details matter. What are the areas that are ripe for undergrounding in 2018? Let’s take a look at the landscape. Capabilities are unbundling across a diverse set of form factors, with new modalities and we are moving past the world of:

  • mobile == certain size screen, touch, camera, and location
  • desktop == keyboard, mouse, another size screen.

If you heard about the recent “Made By Google” event, you would have seen how these things are blurring (touch on laptops, voice and screens together, etc) and we haven’t even gotten to the world of mixed reality and friends.

What are the “jQuery of today” fashions around us? The world of React and Vue add to Web Components to show a world of strong componentization. We can also see other point solutions that many of us are using, e.g. fonts (google fonts and typekit), analytics (google analytics and friends), and adtech (has a huge impact on performance).

There is a lot of fertile ground, and I have been reflecting on:

UI Components


We have a series of components baked into the Web, but as we opened up the ability to create your own with custom elements, we slowed down any that just come with the platform. We started with a myriad of document related tags (including many that we rarely use…. <aside> etc). Then we had form controls, and shoved a universe into type=”mwhaha” on input. I think it would be worth spending more time on the UX of these form controls. It often feels like we get a lowest common denominator out there (which maybe works when we wire it to the native platform) and the user has to do something custom, from scratch, if they want it to differ in any real way. Now, I am looking at type=date, and the type=number where I picture users seeing tiny up and down arrows. We should allow developers the ability to style form controls easier, which would also help a lot with accessibility. This isn’t easy to change, for sure, and the edges are rough.

Left shows the old version, right shows Chrome 64 (thanks Henry!)

In other areas, we did keep iterating. For example, the first image picker on Android had an incredibly weak UI, with a simple file picker, compared to native apps that would show you recent photos that you quickly tap on to be done.

Then we had the need for application UI controls, going beyond documents and forms. How often have I heard:

“Just give me a UITableView that works!!!!!!

Often.

And you can say the same for many other common components. Surely, a developer can hunt around and maybe find a Web Component, or a component tied to a framework, but for many of these the platform could do more heavy lifting AND not require the download and runtime costs.

NOTE: Giving everyone the ability to build components in the platform is a huge win in my book. I am excited that I can build a leaf component that I know will be reusable for a long time to come, no matter which set of libraries of framework I am using in the future. In larger companies, you almost always see multiple frameworks in use (*takes a peak in google3…. oh my!*), so why not at least have the capability to share. This doesn’t mean that you leave your framework of choice behind, far from it. You will see some great examples at the upcoming Chrome DevSummit that marry custom elements with frameworks!

App Architecture

It’s not just about visual components. There are common app architecture patterns that we drag around with us. I would love the platform to offer me a rich state machine with a reactive data flow. For the devices that we run on, and for the multi-modal world, we need to think about how to offload work from the main UI thread. The browser continues to do more and more of this (e.g. compilation of JS, image decoding) but we also need to do more for developers to give us units of work that we can decide where to run. We are seeing good work here via APIs such as Workers (Comlink, WorkerDOM), and Worklets:

I start to get really excited about this world. If we put it all together, we can get a Web that finally has truly reliable jank free fluid UIs, with fantastic components, and needed architecture pieces, allowing the frameworks to up level and work on the next key areas of exploration.

The Web is all about collaboration. I am enjoying working with the community and especially the framework world. But what about yourself? What would you like to see?


I am enjoying Paul Lewis and Surma chatting about some of the possibilities, and how to keep a clean main thread, so you may too: