Tag Archives: google

Fixing AMP

When I first wrote about Accelerated Mobile Pages, there wasn’t a true implementation. Now we see how Google is rolling this out, and it has problems. John Gruber uses Ars Technica as an example:

On desktop browsers, these URLs do get redirected to Ars’s website. But on mobile they don’t. Share from one mobile device to another and nobody ever leaves google.com. Why would any website turn their entire mobile audience — a majority share of their total audience, for many sites today — over to Google?

Maybe this is inherent in how AMP works, and we should have predicted it. If Google’s AMP implementation must run in browsers, will there always be a layer of JavaScript and custom URLs that hide the original web site?

I’d prefer if Google added AMP support directly to Chrome. While it would be a much more limited rollout, it would feel more natural, with fewer drawbacks for publishers.

Competing news platform Apple News isn’t problem-free either. The apple.news:// shared links also add a redirect, with inconsistent behavior since not all platforms and countries even support Apple News. Apple News is an RSS reader that’s designed like a closed platform.

I want the web to be faster. Breaking links should not be part of the solution.

Apple’s control over app hosting

High-profile app rejections aren’t as common as they once were, so it’s even more shocking when an entire developer account is banned from the App Store. Dash from Kapeli ran into this after trying to migrate an account:

Today I called them and they confirmed my account migration went through and that everything is okay as far as they can tell. A few hours ago I received a “Notice of Termination” email, saying that my account was terminated due to fraudulent conduct.

Brent Simmons writes about the lack of transparency and minimal appeal process:

While this is legal, and within Apple’s rights, it’s not what we’ve come to expect from a moral judicial system. No matter what the context, we expect that the accused see the evidence against them, we expect avenues for appeal to be made available, and we expect proportional penalties.

I hope this misunderstanding with Dash will be cleared up soon. But issues like this will never completely go away until Apple separates app distribution from curation. As long as there is a centralized, tightly-controlled system for installing iOS apps, mistakes will happen.

Imagine instead if the App Store worked more like the web. Google dominates search, but they can’t shut down your web site. If you try to game the system, Google can remove you from search and limit your exposure. Likewise, developers should be able to distribute iOS apps with minimal involvement from Apple, yet apps that haven’t passed formal review won’t be searchable without a direct link, won’t ever be featured, and won’t show up in the top 100 lists.

A more open system for app distribution would cleanly solve several problems with the App Store. Apple would be more free to remove clutter from search results without necessarily purging apps from the store. And there would be a natural temporary consequence for suspected fraudulent behavior: simply demote the app, delisting it from search and featured collections.

Apple should focus on highlighting the best apps within a system that lets the app review team make occasional mistakes. There shouldn’t be such an easy toggle that wipes out an indie developer’s business.

Core Intuition 253 and Google

We posted Core Intuition episode 253 this morning. From the show notes:

Manton and Daniel discuss Manton’s experience at the Release Notes conference, talk about the rationale for supporting what might be considered edge-case behaviors in apps, and dig deeper into questions of freemium pricing, reflecting on the Omni Group’s pertinent announcements. Finally they talk briefly about Google’s latest announcements and what their competition means to Apple.

Google must be doing something right with their announcements, because yesterday my son told me he wants to get a Pixel when it’s time to replace his iPhone 5S. And as much as I love our Amazon Echo, I can see Google Home taking off if it’s well-integrated with existing Google services.

New Core Int, Technical Foul, and Timetable

I somehow recorded 4 podcast episodes this week. We just published episode 233 of Core Intuition, where Daniel Jalkut and I talk about the announcements from Google I/O and compare the latest Swift 3 news to our experience going through previous Apple transitions. From the show notes:

“Manton and Daniel react to Google’s I/O keynote, and weigh the threat of Allo to iMessage. They celebrate Apple’s WWDC promotion of 3rd party events, and the increasing speed of App Store reviews. Finally, they reflect on the announced delay in Swift 3’s planned ABI stability, and Daniel’s sudden FUD about embracing Swift.”

It was a big week for the NBA, too, with the first couple games of the east and west conference finals. On the latest Technical Foul, Ben Thompson and I recap round 2, especially the Spurs loss in 6 games to the Thunder:

Ben and Manton are back geeking out about the NBA. This week we talk Manton through the Spurs loss, discuss OKC versus the Warriors, and whether the Cavs are good enough.

And finally, I published 2 episodes of my microcast Timetable earlier in the week. Episode 22 was about dealing with recent stress — trying to see the bigger picture and focus on the good things. Episode 23 was about how to tell when it’s time to move on from a failed product.

Wanting an open voice assistant platform

I’ve owned an Amazon Echo since it first shipped and it’s great. I also use Siri and like it, though I use it less often for the kind of random questions I might ask Alexa. But after watching yesterday’s Google I/O keynote, I can’t help but feel that eventually Google is going to be far ahead of Amazon and Apple in this space.

Here’s John Gruber writing at Daring Fireball about the keynote:

Google is clearly the best at this voice-driven assistant stuff. Pichai claimed that in their own competitive analysis, Google Assistant is “an order of magnitude” ahead of competing assistants (read: Siri and Alexa). That sounds about right.

The problem with a voice assistant is that the better it gets, the more you want it to do. You continue to ask it more complicated questions, pushing at the limits of the assistant’s capabilities.

Only Google has the expertise in web services and the massive amount of data to keep going beyond basic questions. I expect both Siri and Alexa will hit brick walls that Google will get past, especially in conversational queries that let the user drill down below the most popular, superficial facts.

That is, unless Apple can open up Siri. Not just plugging in new trigger keywords like Alexa’s “skills” API (which would be a good start), but maybe a complete way to extend Siri with third-party code that feels seamless to the user. Surfacing voice-enabled apps automatically through natural queries might be on the same scale of app discoverability as we saw when the App Store launched.

As Ben Thompson lays out well in today’s essay, Google faces a different internet than the open web on which they built their search engine. The default for all these new platforms — from Facebook to Siri to the App Store — is to be closed. There’s a narrow window, right now, for someone to take the lead on creating an open voice assistant standard built on the open web.

Buytaert on the open web

Dries Buytaert, founder of Drupal, gave a talk at SXSW this week and wrote a blog post about saving the open web from large, centralized platforms:

“I worry that some of these platforms will make us lose the original integrity and freedom of the open web. While the closed web has succeeded in ease-of-use and reach, it raises a lot of questions about how much control individuals have over their own experiences.”

Matt Mullenweg linked to it and added: “I agree with and endorse basically everything in that post.”

App review for the fast web

Facebook continues to roll out their Instant Articles format to more publishers. It’s now available to anyone, with this catch:

“You won’t be able to publish Instant Articles until your RSS feed has been approved.”

That’s just what we need: the worst part of the App Store approval process applied to the web. No thanks.

Google’s competing Accelerated Mobile Pages has problems too, as I mentioned in the last half of this post about the cost of links. Although unlike Facebook, which wants to trap content behind their own platform, AMP is at least more open and useful to the larger web.

I hate to say it but neither Instant Articles nor AMP are really good enough. I think we need a third standard for super-fast web pages. (Or do we? Maybe the web is okay as-is if we fight page bloat.)

Lighter, faster mobile web

Speaking of the health of the open web, Maciej Cegłowski gave a talk on web page bloat at the Web Directions conference, and he put the slides and notes online (via Daring Fireball). It’s fun to read and there are many great points, but I want to focus on Accelerated Mobile Pages:

“The AMP project is ostentatiously open source, and all kinds of publishers have signed on. Out of an abundance of love for the mobile web, Google has volunteered to run the infrastructure, especially the user tracking parts of it.”

Sarcasm aside, I think Google’s involvement is mostly transparent, and I was hopeful about it when I wrote about this in November. Google wants the web to be fast. A faster web includes more ad impressions and is more competitive with native mobile apps. I don’t think this disqualifies Google from proposing this project.

High Scalability has a long article exploring AMP:

“Google needs an open and rich ecosystem of knowledge. If that’s not there then Google search won’t be relevant. Which is Google’s direct self-interest, which is also the same objective of the publisher. Publishers need access to an open ecosystem of distribution. Otherwise they’ll have a harder time building audiences if they have to appeal to closed platforms. Yes, Google is a private company that has business interests, but that philosophy and that core similar objective is something very important when considering Google’s role in AMP.”

I’m willing to give Google the benefit of the doubt on AMP. The alternatives are too focused on specific platforms and so even less available to the rest of the web.

Accelerated Mobile Pages from Google

The project technical overview for AMP has the goals and basic info. In a nutshell, the new format encourages a return to more bare-bones HTML, with some added functionality for common web patterns. On the balance between bloated ad platforms and user experience:

“Embedding an ad or analytics often implies giving up control of what eventually happens to a site because they can typically inject any JavaScript they want into pages. AMP HTML does not allow this. We realize that both ads and analytics are an important element of monetization on the web, and so we need to support them: our goal is to realign monetization with great user experience.”

Instead, “tracking pixels” are used for analytics. These should be easily skipped by ad blockers, but apps that support AMP will need to use a custom web view anyway, where ad blockers on iOS aren’t allowed. This may continue to limit the appeal of Safari View Controller.

Wired covers the announcement and describes how AMP might be integrated into Twitter and other native apps:

“One surprise beneficiary of AMP may be Twitter. While it’s not a publisher per se, it’s becoming an increasingly important player in news, most recently with the launch of its Moments feature, which makes news easier to follow on Twitter by organizing Tweets in a chronological, coherent timeline. Now, Twitter will automatically load any articles that are compatible with AMP as AMP files, meaning they will benefit from the same speed inside the Twitter app.”

There’s more on GitHub. On the surface this seems like a more open approach than Facebook Instant Articles or maybe even Apple News Format (which is finally public). That WordPress is supporting AMP is a good sign.

Peace for the web

I haven’t paid too much attention to ad blocking until this week, even though I had been running the iOS 9 beta since WWDC. Several content blockers were released yesterday, like Marco Arment’s new app Peace. Marco writes:

“You won’t believe how fast browsing the web can be without the bloated, privacy-invading junk that too many publishers force on you without your knowledge or consent.”

Today, Nilay Patel has an essay framing the issue as a fight between Apple, Google, and Facebook, with the web as a casualty:

“And with iOS 9 and content blockers, what you’re seeing is Apple’s attempt to fully drive the knife into Google’s revenue platform. iOS 9 includes a refined search that auto-suggests content and that can search inside apps, pulling content away from Google and users away from the web, it allows users to block ads, and it offers publishers salvation in the form of Apple News, inside of which Apple will happily display (unblockable!) ads, and even sell them on publishers’ behalf for just a 30 percent cut.”

I’m conflicted on this. I hate ads, and I think good publishers can adapt, but I’m also concerned that some progress we’ve made in native apps and user experience could be offset by steps back in open platforms. The health of the open web is more important than any one company, including Apple.

Google Photos

Tim Cook spoke recently about privacy and cloud services:

“You might like these so-called free services, but we don’t think they’re worth having your email or your search history or now even your family photos data-mined and sold off for God knows what advertising purpose.”

I’m going to give you a very cynical translation, which I don’t often do: We are in denial about how much better Google Photos is than what we’re doing at Apple. It is so advanced in terms of search that we won’t be able to match it anytime soon. In fact, we don’t even have anyone working on similar technology at all.

It’s not about being free. I pay Dropbox $20/month to be grandfathered into 2 TB of storage so that I can put all of my photos and documents there. Dropbox is rock solid and worth it.

Like Marco and others, I have tried to avoid Google services. I don’t use Gmail. I hate advertising. But the idea of being able to quickly search my photos by content without even tagging or organizing them was too compelling to not try. So I’ve uploaded over 10,000 photos so far to Google Photos. It is really good. (I’m going to finish uploading all my photos and give it a few months before making a final judgement on the search vs. privacy trade-off.)

Some of the random searches that work out of the box to filter my photos: “beach”, “trains”, “New York City”, “Oregon and 2013”, “road trip”, “party”, “basketball”, “Christmas tree”. I never saw a demo or tutorial for how to use Google Photos; I just type stuff in and it mostly works, discovering photos and events. And on top of that, there’s also the automatic stories and collages, which is something we always wanted to build for Sunlit.

My family photos are the most important files I have on my computer, and I very rarely share any photos of my kids publicly. But ironically I’m willing to overlook some of the privacy concerns around this exactly because the photos are so valuable to me. I want multiple copies in the cloud, and I want the power of search that Google has built.

Swift or Android

I was nodding my head while listening to the latest Developing Perspective yesterday. David Smith talked about all the work to update his apps for iOS 8, starting on Apple Watch apps, and so taking the pragmatic approach to keep using Objective-C rather than dive into Swift.

Then I read this by Russell Ivanovic on getting started with Android development:

“It’s really not that hard to get started, but you have to be realistic. If you want to get somewhere, you’re going to have to invest some time. If you want to build a viable business on Android like we have, that might end up being a lot of time. I really feel like 2015 might be the only window you’re going to get though, before Google Play becomes as hard to succeed in as the iOS App Store.”

And I thought, getting up to speed with Swift is probably not that different than learning Android. I’ve programmed Java before, but don’t know the UI frameworks; I know the Cocoa frameworks, but have never programmed anything significant in Swift. Both would require setting aside current priorities and investing some time in a new language or new tools.

If I had to build an app in either as quickly as possible, choosing Swift would certainly be faster. I’m just not sure it would actually be a better use of my time than poking around in Android.

Google Fiber in Austin

Google Fiber is coming to Austin next year, with crazy-fast 1 Gbps speeds. It was all over the local news in Austin yesterday.

Although I’ve been trying to slowly move off of Google services, this would probably be too good a deal to pass up. However, it seems very unlikely that my neighborhood — which is in the city limits, but pretty far away from central Austin — will get fiber anytime soon. Definitely not in the first year. From the Statesman’s FAQ:

“The coverage is limited to the city of Austin, although Google did not get specific about geographic boundaries. Representatives said they don’t have plans to add Round Rock, Kyle or San Antonio as part of this roll-out. In addition to homes, Google will also provide Gigabit to about 100 public organizations that the city of Austin has helped choose.”

We don’t even yet have Verizon FiOS in our neighborhood, and that has been rolling out in the Austin area for a while now. Time Warner Cable is still the dominant provider.

Another interesting angle to the announcement: each Google Fiber customer also gets 1 terabyte of Google Drive storage. This sounded like a fantastic deal until I checked the normal Google Drive plans. They already have a 1 TB plan at $50/month, with more expensive options all the way up to 16 TB. (Dropbox stops at 500 GB unless you jump to their business-level “teams” plan.)

Maybe that is the first killer app for fiber. Not syncing files, as Dropbox pioneered, but cloud storage that is fast enough to be more like an extension of your local hard drive than a mirror of it. Something like Apple’s Fusion Drive, but where the slow hard drive is the cloud, and the SSD is just a local cache.

Replacements for Google Reader

With the success of Tweet Marker, several people suggested I should build a sync server for RSS. This was last year and earlier this year, before Google Reader officially shut down, but after it was clear that we needed something better. I jotted down some notes for a couple ideas but ultimately decided not to do it. I’ve already got my hands full with my current shipping products!

Luckily many great developers are now on this. Feed Wrangler from David Smith, hopes for a possible NetNewsWire Cloud, more interest in Fever, and other established web apps like NewsBlur and Feedly. As Marco Arment said, this could end up being a great thing for innovation in blogs and RSS again.

But just because I’m going to watch on the sidelines for the server sync part of RSS, doesn’t mean I’m going to completely skip building better RSS support into my own products. There’s a lot I’d like to do with client-side RSS support in Watermark.

Announcing Searchpath

Today I’m happy to announce my new web app: Searchpath. It’s search for your web site or blog with an innovative “popover” UI. Simple, fast. With better control of your search results, and no need to link to Google or show ads to your readers.

There are so many sites out there that don’t have search, or have very poor search. I wanted to build something that makes setting up a great search box on your site absolutely trivial.

Searchpath knows about blogs — it finds the text on your page to index, and can automatically strip out redundant titles from posts for clearer search results. It tracks popular search terms. It gives you more control, by letting you exclude archive pages and customize the font and links with CSS.

I’m running it now on this blog. Check it out in the sidebar, or visit searchpath.io to sign up and try it on your own site.

Indexing the hidden web

There has been some good commentary on Sergey Brin’s interview with the Guardian. It’s probably best summarized in John Gruber’s comment:

“The assumption here is that the only way to search is through Google, and that the ‘open Internet’ is only what Google can index and sell ads against.”

This resonates with me because I think Google has put enough ads on the internet. It’s impossible to take anything Google says at face value if they talk of “open” but their intentions say “ads”. But here’s the thing: Brin is actually right. There is great data hidden behind apps that should be indexable.

In the race to win the App Store, we forgot about the web. Think about Instagram. Millions of photos are being shared that are inaccessible via a search engine. These photos can’t be found again and aren’t discoverable. When you search the web, how does it make sense that public photos on Flickr show up, but public photos on Instagram do not?

We shouldn’t have to choose between Apple’s closed systems and Google’s ad-driven business. I want to talk about improving the web without automatically being pro-Google. This tweet from John Marstall made me realize it:

“I’d prefer to separate ‘indexable’ from ‘indexable by Google.’ Yes, they’re mostly the same for now. Might not always be.”.

We need competition in web search. More than Bing. A new search engine is the number 1 item from [Paul Graham’s frighteningly ambitious ideas](http://www.paulgraham.com/ambitious.html(:

“The best ideas are just on the right side of impossible. I don’t know if this one is possible, but there are signs it might be. Making a new search engine means competing with Google, and recently I’ve noticed some cracks in their fortress.”

Of course it’s crazy, but so was the 1st search breakthrough, lightning-fast AltaVista, and so was the 2nd major innovation, Google itself. It’s time for a search engine that isn’t all about ads. It’s time for search that understands apps and embraces data from web services as much as it does from web sites. It’s time for the 3rd act in search.

Android and getting real

“Steven Frank”:http://stevenf.com/2007/11/try_again.php on Google’s phone announcement:

“Find someone, ONE person, with a unique vision. Lock them in a room with some programmers and a graphic designer. Twenty people, tops. Change the world. Quit re-hashing the same old bullshit and telling me it’s new, exciting, or in any way innovative. Be ready to fail, many times, but for love of all that is holy take a stand on something.”

I heard about the Google phone consortium pretty much exclusively through Twitter, and the reaction seems about universal from the folks I follow (admittedly, half of them are total Mac geeks). I’m honestly not sure how the Google phone is relevant to me, but then again, I don’t like Gmail.

Although this week’s “37signals post on personas”:http://www.37signals.com/svn/posts/690-ask-37signals-personas isn’t about Android, some of the points are relevant to committee-led design:

“I don’t think you can build a great product for a person that doesn’t exist. And I definitely don’t think you can build a great product based on a composite sketch of 10 different people all rolled into one (or two or three).” […] “Every product we build is a product we build for ourselves to solve our own problems.”

Not using your own product can turn into a real problem, and I realized after I bought an Apple TV that “Wii Transfer”:http://www.riverfold.com/software/wiitransfer/ suffered from it. So I forced myself to use my own product instead, and that made all the difference. Plus, it was easy to unplug the Apple TV because the thing got so hot I was worried it would burn the house down while I slept.

Mediocrity is the new application platform

Today marks the 4-year anniversary of this weblog. What better way to celebrate than with a discussion of web applications.

Willie Abrams said in a recent Campfire chat: “Web applications automatically have sync.” He hits on the fundamental principle of web applications popularity, and of course that has always been true. But the difference now is that some web apps are actually fast and usable too. (Gasp!)

The rise of rich web applications that seamlessly mix Flash or Ajax while still staying true to the roots of web architecture (REST design, open standards) has upset the traditional desktop market. I first wrote about this in “To-do lists and embracing the network”, which was in a sense a subtle wake-up call to Mac developers: adapt to the always-on internet or any college drop-out with a shared server will obsolete your app after a few late nights of Rails hacking.

But it frustrates me to see such praise given to web applications that, were they traditional, native apps, they’d be laughed away to obscurity or ignored. Ajax is a huge advancement, but that doesn’t mean that every application works well for the web. I’m sure Google engineers spent an incredible amount of work on Google Pages, but compare it to Apple’s iWeb and it becomes obvious how weak web application interfaces still are.

Luckily some people are working through the really tough problems. Ray Ozzie’s Live Clipboard may be the start of a whole new shift in web app functionality, allowing data to move between web sites and even out of the browser. But true drag-and-drop of structured data between a native app and a web site is still a long way off.

Let’s make some lists, starting with the good.

  • Good web applications are data-driven, multiuser, and use URLs everywhere.
  • There is some key component that is about the browsing experience. That might be sifting through large amounts of data, viewing old logs, finding people.
  • The kind of data requires an adaptable user interface, not something with a strict set of traditional widgets. HTML is perfect for this.

On the other side are web applications that might be built by a team of smart people and with a great technology backend, but the application concepts are confused. They don’t know if they belong in a web browser or on the desktop.

  • Mediocre web applications think that a single web browser window is an entire windowing system with movable child windows.
  • No features that actually have anything to do with the web. The result is that it adds no value to the web as a whole.
  • Trying to replace the whole Microsoft Office suite.

Something else is changing in the HTML/CSS/JavaScript platform. In 2004, Joel Spolsky wrote about how instead of picking Mac, Windows, or Linux APIs, developers are building for the web platform and can deploy to any user’s desktop. Cutting-edge web applications push that claim to its breaking point, as differences between Safari, Mozilla, and Internet Explorer often cause headaches for developers. It’s no surprise when Microsoft’s set of Office Live applications require Internet Explorer, but it is note-worthy when Google’s chat interface does not work in Safari. There is now a whole set of web applications that require the latest version of Mozilla and won’t work in anything less.

Five years ago we accepted that web applications were going to be useful but ultimately unfulfilling, joyless experiences. Now most web apps have risen from bad to simply mediocre. The truly great ones have a foundation and design that would still be unrivaled in a desktop app. These amazing apps are not content to reimplement an old application as a web app just to allow use from any machine, but they take it to the next step: rethink the problem, stay agile, and redesign so that it’s not just web-based, but it’s actually better.