Tags: google

329

sparkline

Thursday, May 16th, 2019

Lighthouse | Eric Bailey

What if accessibility were a ranking signal for Google search results?

Here’s a thought: what if Google put its thumb on the scale again, only this time for accessibility? What if it treated the Lighthouse accessibility score as a first-class ranking metric?

Wednesday, May 15th, 2019

A report from the AMP Advisory Committee Meeting – Terence Eden’s Blog

I completely agree with every single one of Terence’s recommendations here. The difference is that, in my case, they’re just hot takes, whereas he has actually joined the AMP Advisory Committee, joined their meetings, and listened to the concerns of actual publishers.

He finds:

  • AMP isn’t loved by publishers
  • AMP is not accessible
  • No user research
  • AMP spreads fake news
  • Signed Exchanges are not the answer

There’s also a very worrying anti-competitive move by Google Search in only showing AMP results to users of Google Chrome.

I’ve been emailing with Paul from the AMP team and I’ve told him that I honestly think that AMP’s goal should be to make itself redundant …the opposite of the direction it’s going in.

As I said in the meeting - if it were up to me, I’d go “Well, AMP was an interesting experiment. Now it is time to shut it down and take the lessons learned back through a proper standards process.”

I suspect that is unlikely to happen. Google shows no sign of dropping AMP. Mind you, I thought that about Google+ and Inbox, so who knows!

Good point!

Friday, May 3rd, 2019

A Conspiracy To Kill IE6

This is a fascinating story of psychological manipulation and internal politics. It leaves me feeling queasy about the amount of power wielded by individuals in one single organisation.

Thursday, May 2nd, 2019

AMP as your web framework – The AMP Blog

The bait’n’switch is laid bare. First, AMP is positioned as a separate format. Then, only AMP pages are allowed ranking in the top stories carousel. Now, let’s pretend none of that ever happened and act as though AMP is just another framework. Oh, and those separate AMP pages that you made? Turns out that was all just “transitional” and you’re supposed to make your entire site in AMP now.

I would genuinely love to know how the Polymer team at Google feel about this pivot. Everything claimed in this blog post about AMP is actually true of Polymer (and other libraries of web components that don’t have the luxury of bribing developers with SEO ranking).

Some alternative facts from the introduction:

AMP isn’t another “channel” or “format” that’s somehow not the web.

Weird …because that’s exactly how it was sold to us (as a direct competitor to similar offerings from Apple and Facebook).

It’s not an SEO thing.

That it outright false. Ask any company actually using AMP why they use it.

It’s not a replacement for HTML.

And yet, the article goes on to try convince you to replace HTML with AMP.

Saturday, April 13th, 2019

Goodbye Google Analytics, Hello Fathom - daverupert.com

Dave stops feeding his site’s visitors data to Google. I wish more people (and companies) would join him.

There’s also an empowering #indieweb feeling about owning your analytics too. I pay for the server my analytics collector runs on. It’s on my own subdomain. It’s mine.

Friday, April 12th, 2019

Google AMP lowered our page speed, and there’s no choice but to use it - unlike kinds

What happens when you’re AMP pages are slower than your regular pages …but you’re forced to use AMP anyway if you want to appear in the top stories carousel.

AMP isn’t about speed. It’s about control.

The elephant in the room here is pre-rendering: that’s why Google aren’t using page speed alone as a determining factor for what goes in the carousel.

Wednesday, March 20th, 2019

Friday, March 15th, 2019

Wednesday, March 13th, 2019

Chromium Blog: Chrome Lite Pages - For a faster, leaner loading experience

My first reaction to this was nervousness. Of all the companies to trust with intercepting and rerouting page requests, Google aren’t exactly squeeky clean, what with that whole surveillance business model of theirs.

Still, this ultimately seems to be a move to improve the end user experience, and I’m glad to see this clarification:

Lite pages are only triggered for extremely slow sites, so we encourage developers to measure how well their pages are currently performing over slow networks.

Lite pages as a badge of shame (much like AMP in my eyes).

Wednesday, February 20th, 2019

Minimal Google Analytics Snippet | Minimal Analytics

If you really, really have to add Google Analytics to a sites, here’s a way to do it in a more performant way, without the odious Google Tag Manager.

Saturday, February 9th, 2019

PWA2APK- Convert PWA to APK file - Appmaker.xyz

This seems to work quite nicely: convert your progressive web app into an APK file that you can then submit to the Google Play store (you’ll still have to go through all the hassle of submitting the app, but still).

I tested this with The Session and sure enough, it looks like it’s available to download from Google Play.

Sunday, January 27th, 2019

No More Google

A list of alternatives to Google’s products.

Sunday, January 13th, 2019

Code print

You know what I like? Print stylesheets!

I mean, I’m not a huge fan of trying to get the damn things to work consistently—thanks, browsers—but I love the fact that they exist (athough I’ve come across a worrying number of web developers who weren’t aware of their existence). Print stylesheets are one more example of the assumption-puncturing nature of the web: don’t assume that everyone will be reading your content on a screen. News articles, blog posts, recipes, lyrics …there are many situations where a well-considered print stylesheet can make all the difference to the overall experience.

You know what I don’t like? QR codes!

It’s not because they’re ugly, or because they’ve been over-used by the advertising industry in completely inapropriate ways. No, I don’t like QR codes because they aren’t an open standard. Still, I must grudgingly admit that they’re a convenient way of providing a shortcut to a URL (albeit a completely opaque one—you never know if it’s actually going to take you to the URL it promises or to a Rick Astley video). And now that the parsing of QR codes is built into iOS without the need for any additional application, the barrier to usage is lower than ever.

So much as I might grit my teeth, QR codes and print stylesheets make for good bedfellows.

I picked up a handy tip from a Smashing Magazine article about print stylesheets a few years back. You can the combination of a @media print and generated content to provide a QR code for the URL of the page being printed out. Google’s Chart API provides a really handy shortcut for generating QR codes:

https://chart.googleapis.com/chart?cht=qr&chs=150x150&chl=http://example.com

Except that there’s no telling how long that will continue to work. Google being Google, they’ve deprecated the simple image chart API in favour of the over-engineered JavaScript alternative. So just as I recently had to migrate all my maps over to Leaflet when Google changed their Maps API from under the feet of developers, the clock is ticking on when I’ll have to find an alternative to the Image Charts API.

For now, I’ve got the QR code generation happening on The Session for individual discussions, events, recordings, sessions, and tunes. For the tunes, there’s also a separate URL for each setting of a tune, specifically for printing out. I’ve added a QR code there too.

Experimenting with print stylesheets and QR codes.

I’ve been thinking about another potential use for QR codes. I’m preparing a new talk for An Event Apart Seattle. The talk is going to be quite practical—for a change—and I’m going to be encouraging people to visit some URLs. It might be fun to include the biggest possible QR code on a slide.

I’d better generate the images before Google shuts down that API.

Sunday, December 16th, 2018

Browsers

Microsoft’s Edge browser is going to switch its rendering engine over to Chromium.

I am deflated and disappointed.

There’s just no sugar-coating this. I’m sure the decision makes sound business sense for Microsoft, but it’s not good for the health of the web.

Very soon, the vast majority of browsers will have an engine that’s either Blink or its cousin, WebKit. That may seem like good news for developers when it comes to testing, but trust me, it’s a sucky situation of innovation and agreement. Instead of a diverse browser ecosystem, we’re going to end up with incest and inbreeding.

There’s one shining exception though. Firefox. That browser was originally created to combat the seemingly unstoppable monopolistic power of Internet Explorer. Now that Microsoft are no longer in the rendering engine game, Firefox is once again the only thing standing in the way of a complete monopoly.

I’ve been using Firefox as my main browser for a while now, and I can heartily recommend it. You should try it (and maybe talk to your relatives about it at Christmas). At this point, which browser you use no longer feels like it’s just about personal choice—it feels part of something bigger; it’s about the shape of the web we want.

Jeffrey wrote that browser diversity starts with us:

The health of Firefox is critical now that Chromium will be the web’s de facto rendering engine.

Even if you love Chrome, adore Gmail, and live in Google Docs or Analytics, no single company, let alone a user-tracking advertising giant, should control the internet.

Andy Bell also writes about browser diversity:

I’ll say it bluntly: we must support Firefox. We can’t, as a community allow this browser engine monopoly. We must use Firefox as our main dev browsers; we must encourage our friends and families to use it, too.

Yes, it’s not perfect, nor are Mozilla, but we can help them to develop and grow by using Firefox and reporting issues that we find. If we just use and build for Chromium, which is looking likely (cough Internet Explorer monopoly cough), then Firefox will fall away and we will then have just one major engine left. I don’t ever want to see that.

Uncle Dave says:

If the idea of a Google-driven Web is of concern to you, then I’d encourage you to use Firefox. And don’t be a passive consumer; blog, tweet, and speak about its killer features. I’ll start: Firefox’s CSS Grid, Flexbox, and Variable Font tools are the best in the business.

Mozilla themselves came out all guns blazing when they said Goodbye, EdgeHTML:

Microsoft is officially giving up on an independent shared platform for the internet. By adopting Chromium, Microsoft hands over control of even more of online life to Google.

Tim describes the situation as risking a homogeneous web:

I don’t think Microsoft using Chromium is the end of the world, but it is another step down a slippery slope. It’s one more way of bolstering the influence Google currently has on the web.

We need Google to keep pushing the web forward. But it’s critical that we have other voices, with different viewpoints, to maintain some sense of balance. Monocultures don’t benefit anyone.

Andre Alves Garzia writes that while we Blink, we lose the web:

Losing engines is like losing languages. People may wish that everyone spoke the same language, they may claim it leads to easier understanding, but what people fail to consider is that this leads to losing all the culture and way of thought that that language produced. If you are a Web developer smiling and happy that Microsoft might be adopting Chrome, and this will make your work easier because it will be one less browser to test, don’t be! You’re trading convenience for diversity.

I like that analogy with language death. If you prefer biological analogies, it’s worth revisiting this fantastic post by Rachel back in August—before any of us knew about Microsoft’s decision—all about the ecological impact of browser diversity:

Let me be clear: an Internet that runs only on Chrome’s engine, Blink, and its offspring, is not the paradise we like to imagine it to be.

That post is a great history lesson, documenting how things can change, and how decisions can have far-reaching unintended consequences.

So these are the three browser engines we have: WebKit/Blink, Gecko, and EdgeHTML. We are unlikely to get any brand new bloodlines in the foreseeable future. This is it.

If we lose one of those browser engines, we lose its lineage, every permutation of that engine that would follow, and the unique takes on the Web it could allow for.

And it’s not likely to be replaced.

Friday, December 7th, 2018

Goodbye, EdgeHTML - The Mozilla Blog

Mozilla comes out with all guns blazing:

Microsoft is officially giving up on an independent shared platform for the internet. By adopting Chromium, Microsoft hands over control of even more of online life to Google.

Thursday, December 6th, 2018

Microsoft Edge: Making the web better through more open source collaboration - Windows Experience BlogWindows Experience Blog

The marketing people at Microsoft are doing their best to sell us on the taste and nutritional value of their latest shit sandwich piece of news.

We will move to a Chromium-compatible web platform for Microsoft Edge on the desktop.

You keep using that word. I do not think it means what you think it means.

Wednesday, December 5th, 2018

While we Blink, we lose the Web

Losing [browser] engines is like losing languages. People may wish that everyone spoke the same language, they may claim it leads to easier understanding, but what people fail to consider is that this leads to losing all the culture and way of thought that that language produced. If you are a Web developer smiling and happy that Microsoft might be adopting Chrome, and this will make your work easier because it will be one less browser to test, don’t be! You’re trading convenience for diversity.

Risking a Homogeneous Web - TimKadlec.com

When’s the last time you can remember that a framework was given preferential treatment like AMP has been given? You could argue that it’s a format, like RSS, but no one has ever tried to convince developers to build their entire site in RSS.

I’m with Tim on his nervousness about Google’s ever-increasing power in the world of web standards.

Monocultures don’t benefit anyone.

Monday, November 12th, 2018

Home  |  web.dev

I guess this domain name is why our local developmemnt environments stopped working.

Anyway, it’s a web interface onto Lighthouse (note that it has the same bugs as the version of Lighthouse in Chrome). Kind of like webhint.io.

Friday, November 2nd, 2018

Google Walkout Organizers Explain Their Demands

This instance of collective action from inside a tech company is important, not just for the specifics of Google, but in acting as an example to workers in other companies.

And of all the demands, this is the one that could have the biggest effect in the US tech world:

An end to Forced Arbitration.