“””
(W)e know — via copious academic studies — that work-sample tests are the best available method of predicting performance. Many companies in the software industry do not administer work-sample tests during job interviews. Instead, they have a disinterested person who you won’t work with make up a random question on the spot (seriously, this is not only a thing that exists in the world, it is the default hiring method in our industry). The disinterested engineer interviewing you then spends most of their time preening about their own intelligence while ignoring your answer, and returns a decision known to be primarily determined by demeanor, rapport, demographic similarity, and other things which all decisionmakers will profess that they are not assessing for.
“””

Share this:

Having recently played with Amazon and Google’s TV devices, I believe both work great and complement each other well. There’s overlap, but also a lot of unique and useful features of both makes a good case for going with both devices if you want access to a wide catalogue. Here’s a quick run-down.

Caveats:

The Android TV was a Google IO giveaway, I think basically a Nexus Player, but may be some slight differences.

The Amazon device is a Fire TV Stick. You might say a fairer comparison is the “Fire TV”, i.e. the console and not the HDMI stick, the latter of which seems more like a Chromecast unit. But in reality, the Fire TV Stick is more like a full-blown console in a stick. It’s less gruntier than its console counterpart, which may impact on some games, and the remote doesn’t do voice. But the core features are basically the same afaict.

I’m focusing on video apps here and leaving aside games, audio, etc.

Both:

Make video on TV easy. It’s hugely convenient to browse directly on the TV and just hit play. (There are some interesting pros and cons of built-in TV apps compared to the Chromecast model, but I’ll ignore those here.)

Run third-party apps including, most importantly, Netflix, as well as some other video apps on both. The apps on both are limited so far to specific partners, but both have some good apps for audio, photo slideshows, utilities, and so on.

Ship with good, dedicated, remote controls. This is nicer than having to use your phone or a big keyboard. (I never understood how Google TV thought the keyboard remove was a good idea outside of a lab.)

Have nice, fast, UI. They boot quickly (not Chromebook-quickly, but not PC-slow) and respond to remote control interactions without visible lag.

Let you move between phone and TV, with native Android and iOS apps available for video streaming. (Amazon access on Android devices has been a problem in the past, but I found since joining Prime and installing Amazon app, I can play video fine on a Kitkat device.)

Unique features/benefits (relative to Amazon Fire) of Android TV:

Cards interface and search unify content and recommendations across apps. The recommendations are actually valid.

Sideload APKs. I haven’t experimented with this, but it’s possible to send apps to Android TV using Play’s web interface and some messing around. Some supposedly work well so you can use them even if there’s no dedicated TV app.

YouTube app works well and it’s really the first time I’ve spent any time “surfing” YouTube or bothering to setup subscriptions and so on. Note that YouTube is also available on Fire, though it’s a specialised web UI. The UI is surprisingly-well optimised for the big-screen experience and remote but still not as slick or performant as the native Android TV app.

Acts as a Chromecast, opening up the TV to a lot more apps.

Access to Play TV and Movies catalogue.

Unique features/benefits (relative to Android TV) of Amazon Fire:

Amazon Prime. This is the standout feature and makes the content an all-you-can-eat rental plans along the lines of Netflix. The actual content (in UK) I’ve found to be good too, fairly comparable to Netflix and with a lot of shows not available there. (Some of those shows may be available on Netflix US, but not Netflix UK, e.g. Mad Men.)

Access to Amazon’s streaming movie and TV catalogue. This is a separate point to Prime as it’s also possible to buy some titles that are not in Prime. On-demand rentals and purchases is the best of both worlds – the all-you-can-eat model of Netflix with the purchase model of Google Play.

Cheap! The Fire TV Stick is just $39 compared to $95 for the Nexus Player.

Portable. Similar to Chromecast, being a stick means it takes up less space and it’s easy to travel with one for instant hotel entertainment.

Overall I’m happy with both devices and looking forward to their next round of updates later this year. After a series of false starts, TV is finally possible online without fiddling on a keyboard in the living room and running cables to the PC.

Share this:

Paul kicked off an interesting conversation about pros and cons of a public API [1]. The benefits of APIs have been well-cited, certainly valid, and I would also argue in favour of public APIs in many situations. Yet startups like Uber and WhatsApp managed to grow to stratospheric heights without any API. Which begs the question often ignored in some API-gushing circles: In the ROI equation, what are the downsides of publishing an API?

This is a deliberately one-sided post as I wanted to make a reference of all the downsides in one place. Following are the potential cons that should be considered in any pros-versus-cons API feasibility analysis:

Friction and lock-in – APIs are notoriously difficult to upgrade as clients don’t want to keep updating their code. So once you publish a production-ready API, you have a long-term commitment to maintain it even as you grow and shift the underlying functionality.

Server load and quality of service – Of course, your servers are going to be doing more work when 50 other clients are connected, or 50x clients if the API clients’ end-users are communicating dirctly with your API. (OTOH they might be unofficially scraped in the absence of an API, in ways that may be even worse because you can’t fully consider cacheability and anticipate what will be called.)

Need a higher-quality API – Before your API is public, you can “fake it till your API makes it”. Meaning that you can put logic in your clients which should really be on the server, but because of other priorities or implementation differences, it’s easier to do a quick job in the client(s) [2]. (Which is fine as long as security-critical functionality like input validation still happens on the server.)

Developer Experience cost – There’s no point putting out a public API unless it’s going to be adopted by developers and continuously improved in response to real-world experience. That requires good API design, documentation, developer engagement, and issue tracking. Extra work.

Conflict of Interest – An API invites competing apps cough Twitter cough or even apps that combine several services and thus turn you into a commodity [3]. If you’re a pure “API company”, e.g. Stripe or Twilio, that’s par for the course. If you are more of a UX/app company, it may be an issue depending on your business model. If you’re heavily ad-based and not interested in charging developers, like Twitter, then yes it’s an issue that someone can make a good app without ads. If it’s based on a charge for server-side services, e.g. Dropbox, then no it’s not much of an issue that there are alternative Dropbox apps around [4]. Guardian’s API is an interesting example of a hybrid model which allows the provider to have similar incentives to the developer, at the expense of extra complexity.

Distraction – As well as the extra effort required, the API and surrounding developer relations is adding another department to the organisation, and therefore a new source of management distraction.

<

p>Most companies can and should deliver public APIs at some point and for some functionality. None of the points above argue against that, but should give pause to anyone blindly following the 2010-era doctrine of “API All The Things”.

Notes

“Public” APIs because I take it as a given that any cloud service has a private API. That’s just a truism. Whether companies frame it as an API and benefit from principles of public API design, that’s not always the case, but they have some API either way.

For example, Player FM’s Android app does some search filtering to remove junk results because until recently, the server didn’t provide that.

When Uber did release its first very limited API, it added an exclusivity clause, meaning apps can’t also use Lyft etc APIs, so it avoids direct price comparisons. TweetDeck was also on this path, with its Facebook integration, as was FriendDeck from none other than the man who inspired this post, Paul Kinlan.

It’s still an issue as some of those apps could turn around and provide a one-click conversion to Box, GDrive, etc. But far less concerning that for Twitter, the worry of a stunning Twitter app that doesn’t show ads

Background

Over here, Ade has asked me to permalink a comment I made about moving Player FM accounts from Google Open ID to OAuth. The reason I did it was because Android sign-in is really based on OAuth, but what I didn’t know was Google at the time was preparing to launch “Sign in with Google Plus”, also based on OAuth. Bottom line: Google Open ID, afaict, is going the way of the dodo, so any services using it probably want to migrate their users to G+. (Googlers may please correct me if I’m wrong about Open ID’s demise.)

There were many permutations to be considered for this kind of migration, each with trade-offs to developer complexity and user experience. What follows was the optimum balance for me after a repetition of thought experiments, in between wishing I had a pony (ie that I’d opted for OAuth in the first place, the only reason I didn’t was availability of an Open ID Rails plugin). This is all web-based as we (thankfully) hadn’t launched on Android yet.

The problem

The first concern here is largely about user perceptions. To us developers, Google OAuth and Google Open ID are distinct login mechanisms, as similar to each other as they are to Facebook or Twitter. But to the user, they’re the same thing – Googles all the way down. So you can’t present the user with separate login buttons for Google OAuth and Google Open ID…you only get to present one Big G button.

The other concern is that sites who present “Existing users – log in here” versus “New users – sign up here” buttons … are doing it wrong. A major benefit of third-party sign-in is you can just present a “Connect with X” button and the user doesn’t have to care or remember if they previously connected with X or not. Don’t make me think!

Put concern A together with concern B and Houston, we have a problem. You present that one big G button with Google OAuth and what happens if the user is unrecognised? Is this a new user or someone who had previously logged in using Open ID. (It’s fine if the user is recognised, that means they’re one of the post-OAuth-era people.)

The solution

The solution depends if you’re willing to ask for email permissions on the new oAuth flow.

If you are willing to ask for email, that will make it easy to link the two accounts, because Open ID already relies on email, so you have their email. You can just switch right now to oAuth and once the user authenticates, link the account with the account having the same o8 ID. (Note: this scenario is purely speculative and not based on my experience.)

Since I chose not to ask for email, I had to do the uncool thing and temporarily divided Login from Signup.

In the Login area, the app prompted users for their email or login, and immediately made an XHR call to detect whether that account is using o8 or oAuth, then showed the corresponding button (the button is just a Google button, looks the same either way but the link will be different for o8 vs oAuth). (In addition, the Twitter and classic login form were shown.)

For people who logged in with Open ID, I built an !IMPORTANT! big red notification when the user logged in via Open ID, telling them we’ve updated Google login procedure, and when they click to set it up, taking them through the oAuth flow with a special callback for the migration. At this point, the server recognises the two accounts are linked (they’d already logged in with Open ID, now they’ve just logged in with OAuth), so we can save the user’s OAuth credentials. This user now has two third-party accounts – Google Open ID and Google OAuth. Just as they might also have a Facebook account and a Twitter account.

The Signup area of course only contained an OAuth button (as well as Twitter, which was exactly the same as Twitter in the login area, and classic signup form).

I published advance notice on the blog I would be shutting down the old Google IDs, kept the migration alive for two months, and then deleted all the Open ID accounts at that time. Anyone who didn’t log in at the time lost their accounts, but of course a few people mailed me about it (mainly when we launched the Android app and they tried to log in again), so I helped them migrate manually.

I did this for a couple months before deprecating o8 and returning to the nicer single Google button setup. And just manually merged the accounts when a few users asked me why the Google button is not getting them back to their old account.?

Epilogue

It was well worth the pain, as the vast majority of Android users now choose to log in with Google, even though we also support classic login and guest mode. The G+ API was a big bonus to come out of it. I’ve done some experiments on the social side and expect to do much more with G+ accounts in the future, to help people discover new shows to listen to.

Backstory is I started writing it on Thursday night after seeing all the Reader tweetstorm and figured it’s probably of more general interest, so I submitted it there. The original draft was ~1400 words and I wasn’t sure how seriously they take their guideline fo ~800, so just left it at 1400, but turns out they are, in fact, serious. So we edited it down.

For the record (since some people asked), I used Bloglines for as long as I could cope with its downtime, as I always found Google Reader too magic (unpredictable) with its use of Ajax. Eventually Bloglines was outaging for hours and IIRC whole days, so I made the switch to Reader, but could never get into the web app – too much Ajax magic – and instead used Reeder, sync’d to Reader when it came along. When I switched to Android for my primary device, I couldn’t find a satisfactory app, so just used Reeder on the iPad occasionally.

Meanwhile, with podcasts, I preferred the cloud approach of Odeo and Podnova, but both sadly died. I tried podcasts with Reader, but it just wasn’t the right experience so I mostly used iTunes, and then on Android, mixed it up between several apps (DoggCatcher, BeyondPod, PocketCasts, etc…the usual suspects) until eventually creating my own (still in beta). I really had problems with Listen though, so again, no didn’t do the Reader sync.

So bottom line is I did use Reader “somewhat”, but mostly as an API; and it’s no great loss to me like I appreciate it is to others. The responses to this article certainly demonstrate how passionate people are about a product they get to know and love, and use on a daily basis. It’s never easy giving up on muscle memory. The bright side of the equation is exactly what people like about it: RSS and OPML are open, so at least people can move on to Feedly, Newsblur, and so on. And I truly believe this decision ultimately liberates the standard and allows it to thrive among smaller players.

Share this:

I received today a question often asked about WebWait, so I’ll answer it here for reference.

WebWait User asks:

I have been using webwait for a while and have a quick question for you. When running multiple calls on the same website, is each call downloading the entire page again, or is the information being loaded from the browser cache?

My answer:

It will do whatever the browser would do if the page was loaded normally, so that would usually mean the 2nd-Nth time it will download from the cache. To counter-act that, you can simply disable your browser cache while performing your tests. Or if you do want to test cache performance, just open your site once (either in the browser or WebWait) and then start the WebWait tests, obviously keeping the cache enabled throughout.

Share this:

Google announced a slew of identity and social updates today, most excitingly, the ability to browse users’ social paths. This happens after similar services recently blocking some folks from doing so, which tells you Google gave it due consideration and is committed to supporting this feature indefinitely.

Here’s how the authentication looks:

Now there’s a whole set of widgets and JavaScript APIs, but I was interested in the regular scenario for apps already using the “traditional” OAuth 2 dance. After asking on the G+ APIs community, I was able to get this running and I’ll explain how below.

Step 2. Scroll to the interactive part below and turn on OAuth 2.0 on the top-right switch.

Step 3. To the default scope, add a new one: https://www.googleapis.com/auth/plus.login. That’s the magic scope that lets your app pull in social graphs.

Step 4. For userID, enter “me”. For collection, enter “visible”. (This collection property, representing circles/people the user can identify to the app, only has that one value at present.)

Step 5. Now hit execute and (as a test user) you’ll see the dialog shown at the top of this article. Then hit accept.

Step 6. I got a confirmation dialog saying “Clicking Confirm will let Google APIs Explorer know who is in your circles (but not the circle names). This includes some circles that are not public on your profile.” which is surprising as I believe circles are always private (for now), so I guess users will always see that. Accept it.

Step 7. The JSON response will now be shown below the form. It includes a top-level field called “items”, which is the list of your (the authenticated user’s) G+ people. If the list is too long, there will also be a “nextPageToken” field so the app can page through the list.

So that’s an overview of the new G+ social API. It’s a straightforward OAuth implementation and should be easy for anyone with a Google login to adopt. I’ve been looking forward to adding this functionality on Player FM so people can see what their friends are listening to … I think it’s a nice model where users can choose how much of their social graph they share with any app.

Share this:

Mid-Range Tablets: Their Time Has Come

I was initially skeptical about mid-range tablets. I figured I have my phone in my pocket and my big-ass tablet in my living room; why would I need something in the middle. Niche at best, right?

I was wrong.

I got interested in this form factor when I saw my G+ stream starting to light up with rave reviews about the Nexus 7. Biased crowd, admittedly, but they weren’t the usual fanboys/girls. After Google dropped the price for the holidays, it was too much too ignore. I yoinked a 16GB Nexus for £159 and I haven’t looked back. It’s one of the best devices I’ve owned, up there with iPod, iPhone, and iPad for sheer delight of getting to know it. I find myself reaching for the Nexus even when the iPad 2 is nearby. It’s lighter and less bulky to hold, and works fine for any kind of surfing and reading. (And it doesn’t hurt that it’s running what has become a fantastic OS.) Only video suffers from the size, though the trade-off still makes it worth it for video sometimes, especially in environments like public transport.

The little secret about this form factor, now revealed to the masses, is that it fits fairly comfortably in most adult jeans. Not to mention handbags and glove boxes. I did have a crappy knock-off 7″ model from early 2011, and it was simply too fat to fit comfortably in the pocket. But – thanks mostly to battery improvements, apparently – the Nexus 7 and iPad Mini are way thinner, and that really makes the difference. Furthermore, the grippy backplate of the Nexus 7 is genius, one of those “little things” that makes a huge difference and elevates the form factor overall.

The New Must-Carry Device

Given that (a) mid-range tablets are the sweet spot for many interactions, and (b) they are feasible to carry around, the natural deduction is I want to carry them around with me. Even more so as I’m often using it to listen to podcasts or watch videos prior to stepping out and want to continue that experience without switching over to the phone.

The mid-range tablet has begun to occupy the special place traditionally occupied by the phone: A personal device, always carried. Not a shared device like the iPads of yore, but a device as personal and omnipresent as the smartphone. So I’m often carrying two devices now; the convergence trend has been reversed and after shedding the dedicated MP3 player and camera, suddenly my gadget count has doubled. A smartphone and a tablet, both in my pockets? Don’t want.

Why even bother carrying a smartphone anymore? What does it offer that the mid-range tablet doesn’t? Well, two things for now: Bandwidth and actual phone services.

Bandwidth is mostly what I still need the smartphone for. The S3 has increasingly a dumb appendage which sits in my pocket and is only there to provide tethering support for the Nexus. Well, that happens as long as I have a wifi-only model, but if I could choose again, I’d splurge on a 4G model.

That leaves only one thing the smartphone is good for: the “phone” bit. And that’s why I’m talking about Phablets here. Modern tablets do in fact allow for phone services. We can use VOIP solutions like Facetime, Google Talk, and Skype, all with plenty of options for buying traditional phone numbers and interfacing with the regular network (including SMS and voicemail). Furthermore, it should be possible to access the radio and make actual phone calls using the standard dialling app (requires a rooted Android device for now, but it’s possible). One could easily make regular phone calls with a headset, bluetooth or wired, or speakerphone, or – yes – the comedy scenario of just holding the damn thing to your face for a few minutes.

Having explained why those two barriers are surmountable, I believe Phablet-Only is possible and something I want to do. I think we’ll see a little Phablet-Only trend gain momentum in the next year.

One Size Fits No-one

Phablet-Only is not for everyone. I know. Not everyone wants to interact with their phone using a headset. It’s super-convenient to just hit Call and hold the phone against your face. Others might object to the one-hand experience; if you’re standing on a crowded train every day, you probably want to hold a device where your thumb can reach every point on the screen. And the size itself, of course. If you don’t have big enough pockets and don’t want to carry a bag around, you can’t do this.

The real point is that everyone will have a range of options available. It’s likely that we’ll converge to one personal device, because most people will be too inconvenienced by keeping multiple devices with them at all time. Even with cloud syncing, you still have to install apps twice, set up your homescreen again, etc. Only a revolution in wearable devices, like Google Glass, will bring about more than one device. So assuming for now, we have only one device, what will that device be? In 2009, we could confidently say it will be an iPhone or similar form factor. But for 2013, I believe we won’t be able to say much at all as it could be anything from 3″ to 8″. For Phablet-Only users, they might still keep their phone, but it would switch to a secondary device for occasions where a tablet isn’t practical (e.g., the running/clubbing/gyming scenario). The implications for developers are obvious: Get Responsive! And I mean this in the broader sense: Native apps must be responsive too and designers must consider how different form factors affect different usage patterns.

Share this:

This blog is now hosted on WPEngine. I was having trouble managing it on the Linode VPS for some time now. It seemed to cause DB issues for some reason, which would in turn lock up my other sites (WebWait, AjaxPatterns etc). So I had to isolate it on a separate Linode, and decided if I’m doing that, I may as well just go for a dedicated WordPress host. So here we are at WPEngine. And took the opportunity to cut the clutter and go for a minimalist theme. So thanks Sayanee for this here IceCap theme. Update: Or not. Having some scrolling issues, oddly enough, so reverting back to the old theme for now.Update again: Fixed. It was a conflict with the MailChimp Social plugin. Luckily, Social has an option to disable its own comment view, so I can keep both plugins active.

Share this:

I’ve been blogging about some of my own projects lately, but wanted to capture/announce/disclose/link a few other things I’m please to be involved in:

I’m now a technical advisor to MinuteBox. I’ve been singing these guys praise since I discovered the product at SeedCamp last year. The concept is so damn useful and the founders are capable of delivering on it, so I’m proud to be associated with it.

Judged for Node Knockout. Did so in its inaugural year in 2010, and again this year, now from the perspective of someone who’s Noding daily. My votes.

Judged for HTML5 Open Call, for GDD Russia. HTML5 Canvas and SVG galore! Actually, it was great to see an upswing in SVG use…really, it has a lot of benefits over canvas in some cases, and it seems people are beginning to see it.

Mentoring at SeedCamp next week, as I did last year. Looking forward to seeing what’s new, and I’m pleased to have made lasting connections at the last event (MinuteBox being one of them).

Mentoring at GammaRebels next week (remotely). Looking forward to this event too. Polish startup community is thriving right now.

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff