14 articles Articles posted in Uncategorized

The Rise of the Mobile Web

This is in response to Chris Dixon’s post, “The Decline of the Mobile Web“.

Mobile Web isn’t declining… it’s changing. The whole approach of taking a traditional desktop browser and compacting it for mobile didn’t work. People are realizing that now, and Mobile Web is adapting accordingly.

If you look at this chart, people are clearly spending less time in mobile browsers (Safari, Chrome, etc…) and more time in native apps.apps_dominate_hires-resized-600

From the same article by Flurry, we can see where folks are spending their time – a combined 42% in enablers of Mobile Web (Facebook, Twitter, Social Messaging and Browser)

time_spent_donut_hires_v2-resized-600

Mobile Web isn’t limited to browers – so many apps have browsers built-in, and messaging apps are starting to take this to the next level. It all started with Facebook and Twitter having webviews, enabling quick and easy access of web content, but with poor retention. Kik has the best approach I’ve seen for a new-age “browser”. Built into their messaging system is a browser that takes the best of both worlds (quick and easy discovery + retention).

Because of the Mobile Web, we (Clay.io) have grown by 1.75m new users in the last 3 months with $0 spent on user acquisition – how many native apps these days can say that?

The “open architecture of the web” is a alive and well, albeit a bit different. Mobile Web is on the rise, not decline; it just doesn’t look like its desktop predecessor.

P.S. If you’re someone who wants to hear more on what we’ve learned about the current state of Mobile Web (specifically related to games), shoot me an email – austin@clay.io.

21st Century Carol of the Bells

As part of my Christmas gift to my girlfriend, Rachel, I wanted to do something interesting with technology – specifically the many devices I have at my disposal.

What I ended up building was a “symphony” with multiple phones, tablets, desktops, etc… playing different parts of a song Carol of the Bells.

EDIT: Node server taken down for now… Try it out here

This is the version where every device plays the same part – it’s a bit more visually pleasing than it’s ensemble counterpart:

And the ensemble version where there are four parts split between the devices:

This was hacked up on Christmas Eve, but if you want to dig through the code, it’s on GitHub.

The client connects to a Node.js backend which lets the clients know which audio file to use. Once the sound files are loaded on all clients, an event to play the audio files is sent out (adjusted for latency on each device). The only painful thing here was some of the differences in HTML5 audio implementations on each device… it was easy enough to get the audio files to play, but there were different delays when using audio.play() or audio.currentTime = 0 (and Web Audio isn’t supported enough on mobile).

The four mp3 files are generated from a Carol of the Bells MIDI. To add in the visuals, I converted the MIDI file to an XML format, and again to JSON keeping just the info I needed (when a note is played, and which note).

Analysis of signup methods: Why you shouldn’t ignore Google Federated Login

When we were initially developing Clay.io, we chose to only use Facebook, Twitter, and Email as login options… leaving out Google Federated Login. Google Login is something I don’t see anywhere near as much as I do Facebook and Twitter, which is why I assumed it could be a lower priority. It wasn’t until we implemented it that I realized we were wrong.

I thought it would be helpful if I posted some statistics of the signups we’re getting per login/signup method.

Here is how the signups break down for our 1,058 users at the time I collected data:

We didn’t implement Google Federated Login until we were already at 200 users. Below are the stats for our most recent 835 users.

As percentages: 24.7% Facebook, 10.5% Twitter, 22.3% Google and 42.5% Email.

The main thing I would say to take from this is: using Google as a third option for login is certainly worthwhile. If you are hoping to get the most people signing up, I would use all 3 (+email). If you need to cut one out, give the ax to Twitter. Of course, there is still a lot of value in Twitter (for example if you want to look at their followers and find people within your site to recommend).

Implementing Google as a login option was relatively painless.

The most popular option is still email, and there are sites that don’t allow that as an option… that’s not very smart.

I will mention that a lot of our audience has been from Hacker News, Reddit, and other early adopters. For a more broad population, it’s hard to say how it would be different. Even fewer Twitter users I’d imagine, and perhaps a lower percentage of Google as well.

Some extra stats:

A graph of activity (basically how much a given user plays the games on Clay.io) per signup method. With such a small sample size, a few really active users can throw this off, so don’t read to much into it:

Users on Clay.io can ‘upgrade’ their account to developer status. It basically just lets us know they’re interested in our API and the development side of things. Here’s the same analysis applied to all 143 developer accounts:

It’s a small sample size, but it’s clear the developer types prefer to use email much more than the average user. The percentages are: 12.6% Facebook (half as frequent as the typical user), 9.1% Twitter, 17.5% Google and 60.1% email.

For reference, this is what our signup form looks like. We don’t put too much emphasis on the ‘social’ options, but they are there. In fact, more of our new users come from those 3 options than through email (and we aren’t asking for a lot of information with the email option).

It would be interesting to see how these statistics would look on a much larger site… Any takers on HN?