Brand Loyalty

I was speaking at a conference not long ago on the future of mobile, and during my Q&A I heard a common question: “Will apps replace webapps?”. Hearing that question a lot, I have a standard reply: “Not everyone is going to want to download an app to get an insurance quote”.

I don’t think there is much debate over that. The web let’s you start, without any commitment, using an “application” without the the fuss [1] of engaging the app stores. It’s also platform agnostic, which makes things more efficient for developers (but that’s more about us as developers, and not about the user).

If that was the end of the story, you could say that web apps are “good enough”, in most cases. Why bother building an app, if a web app will do?

I do think you still need an app. It might not be for the new user trying out your service for the first time, but for the loyal custom who wants to keep engaged. I think app indexing [2] makes this hugely obvious, for anyone still in doubt. Your loyal customers will get your search results first, and they’ll be happy about it (hopefully).

App indexing is one example, but that’s just the start. The advantages of native apps will become too extreme to ignore, and your loyal users (the brand loyalists) will want them.

Build web apps to engaged and promote. Build native apps to maintain and delight. I don’t think we have the luxury now of not doing both.

[1] Can apps be used, in some reduced form maybe, without being “installed”? I’d be surprised if Google and Apple are not considering this a possibility.
[2] This is currently Google only, but make no mistake, this will come to iOS as well.

When World’s Collide (Apps and the Web)

Yesterday I decided to watch the Google I/O keynote. I’m glad I did. It gave me good insight into Google’s world, as I think I’ve locked myself too much into thinking of Apple lately.

One key example – App indexing. I’ve argued that Apple will start doing this to curb Google’s dominance in search, but I didn’t realize Google has already started.

Let’s think about the potential impact here. My app data is now included into Google search. A similar website, with the same data, was just replaced. Years and years of SEO planning and content strategy was just brushed aside [1]. And, for the user, goodbye to crappy spam search results.

For Google, you have to ask yourself, why stop there? Google now has a new source for data. Will they start displaying that app data in searches, even if they haven’t installed the app? What would this world look like?

Let’s think deeper though. “Search” is very often the starting point for most people who are using the web. What happens if apps start to replace this? A scary scenario for the web.

The other side of the coin: Google is combining recent apps with recent browser tabs in it’s app switcher. What is an app and what is a webapp?

John Gruber comments on this:

My thinking was similar, but there might be a bigger picture here. This is especially obvious when Google started to talk about the updates on their new Chromebooks. An OS that is supposed to be based off of the web, will now run Android apps.

Google is melding the web and Android together.

If you need more evidence, take a look at their design standards. They’re not just for Android app developers, but also for Web developers. They want the web to even look the same as Android apps.

What is the strategy here? Some kind of Web/App harmony, or (more cynically) Google’s version of “Embrace, Extent, Extinguish”?

UPDATE: Google put Android apps onto their Chrome OS – What if they could put their Android apps into the rest of the web? When I search from Safari on my Mac, could I not only see results from Android apps, but have the app run natively within the browser? Is that crazy? Search for “World Cup” in Google right now, and you’ll see basically a mini-app in the results.

[1] Good riddance.

The State of CMS

I was doing some personal research, comparing the interest in Drupal/Joomla/WordPress over the years.

That seems to be in line with an CMS Trends post I was reading some time ago. You’ve got to look at that chart and wonder how WordPress is able to sustain it’s growth.  I read recently that it now runs 22% of the world’s websites – an incredible number.

On Mobile Menus

Responsive design is a beautiful thing. Sites dance gracefully from one size to another, elegantly displaying it’s contents to any display that comes looking. There is at least one exception though – and it’s a big one. If responsive design is a choreographed dance, the site menu is a dancer with 2 left feet in the front row, who can’t remember the steps.

I don’t think this is controversial to say, considering the recent backlash with the hamburger-style menu (which is the closest thing to mobile web menu design pattern). Mobile menus are awkward. They are often not the helpful tool we require, but the wedge designers use to fit a desktop paradigm into a mobile world.

A menu to me is like a map. A map tries to give you a visual representation of whatever you are mapping, and also suggests how to get where you want to go. A map doesn’t necessarily have to represent it’s subject exactly, however, as long as you are able to get to your final destination. Let’s consider the most popular map: the map of the world. The world map, the one we are all probably used to (in western culture), doesn’t represent the world accurately. It was designed for ocean travel, to help navigators sail the world’s seas.  The subject (the world) is changed for the purpose.  The same can be said about subway maps. They are not 1:1 representation of the subway systems, they are designed to make them easier to understand.

We need to do the same with website menus. We are failing, because we are using maps designed for desktops.

I think a lot of the confusion is using out-of-date terminology. We still consider a website to be … well a “web”. A web is a sprawling thing, with many links, going in all directions. Our desktop menus did an OK job of visually representing this. At a quick glance, we got an idea of the site’s “web”. And, since creating a page doesn’t really cost anything, we can create lots of subpages (we’ll just add a mouseover drop down to the menu so people can find things).

The reason why desktop menus won’t work on mobile, is because the entire site structure is part of the map, and it’s a map designed for desktops. The actual content, the stuff people need to read, is the same across devices, but the way it’s being displayed, and the way it’s organized need to change.

If the desktop websites are a “web”, then mobile websites are a “stream”. Streams not only represent the physical screen layout (which people generally view in portrait mode), it also represents the linear, action-oriented nature of mobile use.

So how do we navigate a stream? I don’t think there is one correct answer to this, but to me, navigation needs to be part of the flow of the content. Navigation needs to be part of the story telling, not an abstract block bolted to the top of pages. On mobiles, the chrome is meaningless, its the content that shines.

Do you want a sneak preview of a mobile navigation built into content? Take a look at the site.

WWDC: Drawing the Lines

I’ve watched every Apple keynotes for a number of years, and this has to be one of the biggest. Apple is really firing on all cylinders. Swift is getting some great reviews, and I think any developer a bit standoffish of Objective C now has their attractive alternative.

I’m also, as a web developer, carrying a lot of mixed feelings.

Let’s try to draw some lines here, because Apple has announced a lot of things, and in no way are all of these things isolated:

New Spotlight updates – Apple introduces enhanced search, not only from iOS but also OSX. Spotlight will search your computer as usual, but now also will expand on specific verticals, like movies or wikipedia results.

Cloudkit – This is Apple’s Azure, a cloud toolkit for developers. Oh and it’s free(ish), but not platform agnostic.

Let’s look more at the thinking around Cloudkit. Sure, it’s free, but how many developers are willing store all of their data where only one platform can access it? Here is a great quote (more of a question) regarding Cloudkit from Citeworld:

If Apple offers some kind of sweetheart deal for its biggest platform partners, it could be attractive. Or, if Apple has something else up its sleeve — deeper iOS hooks, fast-lane to App Store approval, something — to bait the trap, developers may find it’s worth the effort to ignore the usual MBaaS sales pitch and code a different version for non-Apple platforms.

Let’s try to introduce another advantage to using Cloudkit: what if your application’s data could be used in iOS’s main search? This makes a LOT of sense to me, and it’s something I’ve been arguing privately for years.

How would you like to search for BBQ recipes using the data from your three favourite recipe apps? Or, how about searching for BBQs on sale, and get results from your local flier (using data from an app like Flipp).

Those are relevant, personal, and location-focused results Google would love to give you. But it wasn’t given to us by Google, or even from the web… and here is where I start to have mixed feelings. What happens if search, and our data, move from the web?

Here is another thought, if you are not convinced: personal assistants are coming. Siri, Google Now, Katana-make no mistake, this will be one of the biggest features for any future platform. Do you think the web will be the place that’s going to feed your assistant the data it needs? I really doubt it. I think these systems will need a more controlled environment (at least at first). Apple has really dragged their heels on giving 3rd party access to Siri, but maybe now (with Cloudkit) they’ll start opening the gate.