Recently, we’ve been testing some new WiFi access points at work and one of the vendors we’ve wanted to test out their equipment is Ubiquiti Networks.
Hope the following images can give you an idea of what its been like. Well, actually I’ve always wanted to incorporate a Der Untergang parody but till now never found the appropriate occasion.
My last post described a simple personalization feature which could optimise app discovery on both the iOS and Android platforms.
I would like to share a mockup of the Android Market app which shows how apps would bubble up and become more naturally discoverable
Edit: This suggestion is expanded and elucidated more comprehensively in the official Animoca blog post
Mobile App Developers both on the Android as well as iOS ecosystem are consistently looking for more ways to have their apps discovered since they don’t buy in to “If you build it, he will come” philosophy.
Apps are discovered by users in many ways including pervasive marketing via mobile banner ads, video clips, cross promotion ads and very often discovered by users via “ranked lists” whether they be called “Top Charts” on iOS or the various Top Lists on Android Market which are quite well described via in this presentation by Eric Chu at Google I/O 2011.
Developers try very hard to get high up in the overall ranking since that improves organic discovery. This in general involves spending fair bit of money on advertising their app so that maximum users can be made aware of it or if the developer has an existing app or set of apps cross promoting amongst them.
However, lets take the viewpoint of a user who wants to discover more apps. Wouldn’t the user find the Top Lists more useful if they eliminated apps which were already installed on the users account or a device combination. This would allow apps which were ranked lower in the charts to bubble upward and thus users who had already consumed apps in the Top 10 or Top 25 content (the specific list within Android Market doesn’t really) would see other content which may have been below the fold for them and if the voracious consumers found that content to be useful, maybe that would be a signal for the app to bubble faster up the list.
Both Google and Apple have the ability to know what apps have been downloaded by a user specific to a device and/or an account and thus personalise the Top lists by eliminating apps which have already been installed by the user from the Top various lists. They would in effect become “Top lists of apps which have not been installed by the user”
This relatively simple change in my opinion would improve discovery and make the ecosystem more useful to both mobile users and app developers.
Facebook is migrating to OAuth 2.0 (an open standard for authorization) and HTTPS to provide better security on the world’s largest social network. This has some implications for Facebook developers and users, and there are also some items of concern and others that require clarification.
As announced in May on the Facebook Developer Blog, by October 1, 2011, all Canvas apps on Facebook must have completed transition from the old Facebook authentication system and HTTP to the newer and more secure OAuth 2.0 and obtain an SSL Certificate.
One of the ambigious requirements for developers is that they “obtain” an SSL certificate for Facebook Canvas and Page Tab apps. It’s not clear what “obtain” mean.
Are developers just to buy an SSL certificate and prove to Facebook that they bought one or are they required to host the Canvas or Page Tab app under HTTPS
Assuming developers have to host their apps under HTTPS, other questions which arise are
- Will Facebook default to as well enforce HTTPS access for all users on Oct 1 ?
- Will developers have to cater to both HTTP and HTTPS access to their apps ?
- Will Facebook ‘map/redirect’ HTTP traffic to HTTPS ?
Whatever it means, Facebook app developers already have a lot on their plate: viral channels on Facebook are diminishing fast and users are getting more expensive to acquire every day. Additionally, the trend to spend more time on mobile channels results in a reduction of time spent on Facebook Canvas games (many of which are built using Flash/Unity and are thus not available on a large number of mobile devices).
Will these changes hurt small to medium developers in particular? SSL has a reputation of being expensive to deploy and, although a lot of work has been done recently to lower this cost, the software tuning and the know-how for high performance SSL stacks typically exist primarily in large corporations.
Canvas apps can incorporate advertising from Facebook-approved providers, but unfortunately Google AdSense – which offers some of the best eCPM rates – is not one of them. A number of developers have been clamoring for Google AdSense to be included in Facebook’s list of approved ad providers, however nobody seems to be holding their breath waiting for Google and Facebook to come to an agreement.
To ensure a good user experience, all elements in a Canvas page will have to be served over HTTPS; to do otherwise will result in browsers popping up mixed-content warning dialogs that interrupt and bewilder many users.
Additionally, Google’s browser Chrome is moving toward blocking mixed scripting, which is likely to affect non-SSL advertisements on Facebook Canvas pages that are served over SSL.
Are advertising networks ready to serve ads over SSL ? Or will app developers be forced to find some other way to monetize their products if Facebook-approved ad providers are not able to serve ads over SSL?
What will be the impact on their costs if Facebook app developers are forced to use content delivery networks (CDNs) to serve assets over SSL ? Developers also need to be aware that name based virtual hosting is not possible over SSL unless browsers, SSL libraries and server stacks support Server Name Indication.
If Facebook requires developers to provide both HTTP as well as HTTPS access to Canvas apps then that will increase complexity and cost of deployment.
Facebook Credits and impact
Any company or person deploying a game on Facebook must already cope with the mandatory requirement of using Facebook Credits instead of a proprietary currency. Before the requirement to use Facebook Credits, companies offering games and apps via Facebook’s Canvas system would determine their own currency and product pricing, selecting third party payment providers of their choice. For example, a vendor like PayPal used to provide a payment gateway for your Facebook app for a few percent commission on every transaction. The commission on the (mandatory) Facebook Credits system is a whopping 30% on every transaction. So much for the cost advantages of a unified currency!
Facebook Credits provide a fairly liquid unified currency – and that’s good. What’s not so good is that this currency still has a substantial number of zero-value credits in circulation, and users who pay with these “free” credits provide no revenue whatsoever to developers.
One option Facebook app developers can consider is to host the application outside of Canvas and use Facebook’s Graph API to access Facebook platform features. Given that Facebook’s own FBML is deprecated and that almost all Canvas apps today are in iframe, the Graph API workaround is relatively easy and does not constrain developers with various rules (including the need to have the app hosted under SSL).
The ability to use Facebook Credits is obviously not useful or available outside of Facebook Canvas but there are alternatives, including the upcoming Google In-App Payments for the Web (5% fee on every transaction). Perhaps the rise of Android will increase the proliferation of Google Checkout accounts and if Google could address the issue of increased mechanisms of adding funds to Google Checkout accounts this can be a good beginning for the much rumored Google+ Games
Google Checkout limited mechanisms of adding funds and its impact on monetizing freemium Android games
Mobile analytics firm Flurry has an interesting chart showing the rise of freemium games and its impact on the list of Top Grossing Games.
According to them, at the end of June 2011 65% of the revenue generated by the Top 100 Grossing games in the US App Store were freemium games. This is in large part due to Apple having access to over 200 million credit card on file. Apple also makes it convoluted to activate an iOS device without providing a credit card. There is also the ability to buy iTunes gift cards as well as link the iTunes account with Paypal
Compare this to the Android Market where Google provides in-app billing service via Google Checkout. Android usage is booming and activation requires a Google account. However there is no need to create or associate a Google Checkout account during activation.
Also, prior to it use for Android Market the only reason one would have funds in a Google Checkout account would be to pay for extra storage for Gmail or Picasa or buy a premium plan for Google Apps. That’s a fraction of the Android userbase.
If freemium gaming is going to be one of the big drivers for increased Android apps and particularly ports from iOS thereby increasing usage of Google Checkout then it becomes very important to have lots of mechanisms to add funds to Google Checkout in a relatively frictionless manner.
Facebook has spent a lot of effort partnering with alternative top-up mechanisms and now Facebook Credit pre-paid cards are available in a ton of places particularly in South East Asia where credit card penetration is very low and there are established infrastructure for topping up funds to use for micro-transaction payment. Carrier billing is very expensive and this can easily be seen when buying Facebook Credits which cost 3x as much via mobile payments compared to walking to the neighbourhood shop and buying a scratch card.
PowerDNS currently hard-codes the RD (recursion desired) bit to 0 when it sends DNS packets to nameservers configured in its forward-zones/forward-zones-file configuration parameter. This makes it impossible for one to configure an open recursive nameserver such as GPD as a forwarder. There is a ticket open in PowerDNS about it and Bert has mentioned on the mailing list that he is close to making the changes to provide the required functionality. Maybe this feature might come in a future PoweDNS recursor release
Most of the comments which I’m reading about Google Public DNS (GPD) performance centers around round trip latency from an end-users location to GPD’s resolvers vis-a-vis their network location and comparing the round trip time to their local ISP DNS cache. Ping time is only one part of the time taken for DNS resolution, one needs to factor in DNS resolution time also which can be affected by cache locality and sizing as well as how connected the requested authorative nameserver for the query is relative to the DNS resolver. IMHO, an effective way for setting up an office DNS cache is to setup a local caching nameserver such as Dan Bernstein’s dnscache and use GPD as an upstream forwarder.
Thus domains which are repeatedly asked are answered from your local dnscache and the long tail of domains can be answered by GPD which may have its in its cache because what may be infrequent for your organisation is frequent for someone else who is using GPD thus giving you the best of both worlds. Fast local caching, and a fast recursive resolver when you have no locally cached results.
I’m assuming that in the coming weeks, Google will reach out to a number of organisations who use anycast DNS such as Content Delivery Network operators (Akamai, Limelight, CDNetworks etc) and authorative DNS servers operators (Dynect,UltraDNS,DNSMadeEasy etc) and work out better network routing amongst them.
These instructions assume that you have setup dnscache as an external forwarding cache for your organisation.
Then run the following commands (asssumes that you have installed dnscache as per DJB’s setup. Ubuntu/Debian users may have to adjust paths if they use packages from these distributions
echo 1 > /service/dnscache/env/FORWARDONLY echo '22.214.171.124 126.96.36.199' > /service/dnscache/root/servers/@ svc -t /service/dnscache