Open Inventions

The Value of an App

From Google+ post 

https://plus.google.com/111979881434916341479/posts/SV9UDhN6bzY

I recently had to babysit my five year old nephew while all the other adults were out of the house.  So, I did what any enthusiastic Uncle would do.  I spent two hours drawing cars, playing a board game, playing hide and seek, and setting up an experiment from a science kit project.  After two hours, I did what any rookie babysitter would do and collapsed on the floor and let him play with my iPad.  My nephew then starts playing with a Cars 2 Book App.  

http://itunes.apple.com/us/app/cars-2-world-grand-prix-read/id448440398?mt=8

Like any five year old Cars 2 fan, he was instantly addicted.  His favorite characters were at his fingertips; he loved listening to the story over and over again; and most importantly, there was a race track that he could race against other cars.  

What happens next is interesting…

I ask him for the next ten stars he gets for good behavior would he like to get another Cars 2 toy like the one I bought for him two weeks ago or another iPad Book App like the one I bought for him today.

He chose the iPad Book App.

Okay, any teenager would pick a video game over a toy, but a five year old child?  The toy is pretty amazing…

http://shop.mattel.com/product/index.jsp?productId=11213010

Here’s the thing.  The iPad App costs $7 and the toy costs $33.  As a parent, the value proposition is clear.  The App wins.  Now a $500 iPad is an expensive toy for a five year old, but what happens when the iPad 3 comes out and parents can buy a used iPad 1 for $200?  And I think the two bigger questions are:

1) What happens to the physical toy market when more and more younger kids have Tablet devices that their parents give them for edutainment?

2) What happens when a child starts valuing virtual objects more than physical ones?  Especially at such a young age?  Is building a virtual lego set different than a real one?  Will these virtual consumers want to spend more on a virtual cup of coffee one day instead of a real cup of coffee?

iPad for Education

Recently, the Khan Academy open sourced their iPad client.  If you’re not aware of the Khan Academy, just imagine the scene in Forrest Gump where Forrest just keeps on running and running and running and people just join in the phenomenon.  Well, instead of running, Salman Khan just keeps on teaching and teaching.  When you watch one of his videos you realize that Sal Khan is a great educator and he is very passionate about the topics he teaches.  When you see the 250,000 views beneath the YouTube videos you realize that there is a movement to have children be educated from a different medium other than the standard classroom curriculum.

The iPad is a great place for the Khan Academy to go next.  A survey from PBS found 70% of parents willing to have their children use their iPads and 90% of these parents mainly want their children to use their iPads for “educational value”.  When you put an iPad in a child’s hands, you realize how truly engaging the device is.  Tapping and swiping are completely intuitive, navigating the interface makes exploration fun, and most importantly, the sheer volume of apps always keeps the experience fresh.  

Recently, I drove by a Montessori school in Los Angeles and noticed a banner with an iPad on it.  I Googled the school and found a page listing apps they’ve incorporated into their curriculum.  Searching the web, I found more and more resources on how iPads are being used for education.  My five year old nephew is in town for the summer and I’ve started using him as a guinea pig on some of these apps and the results are amazing.  Watching him touch objects on screen and getting immediate feedback with vibrations, animations, imagery, audio, and video makes me realize how much more he’s engaged with the medium.  It’s a different experience than learning on the PC where you click on a mouse.  I believe the physical act of tapping and gesturing on the screen makes the experience feel more real and thus heighten the emotions and strengthens the memories of those interactions.

Yes, pure educational iPad apps will see immense growth but I wouldn’t be surprised to see successful companies start branching out into the physical space also.  I can see apps getting children enthusiastic about a topic which compel them to interact with their real life counterparts.  For example, a child could learn a lesson in optics on the iPad and the same company could offer an optics kit that the child could experiment with.  I’m doing this already with my nephew.  When he’s used up his allotment of iPad time for the day, we continue to play his favorite game in an offline “paper mode” I created.  

What I like about this, is that the iPad game’s high production value addicts my little nephew and makes it very easy for him to crawl into my little web where I then throw math questions at him which he must answer correctly before he’s allowed to shoot peas at zombies and I completely rig the game so that he learns the value of saving instead of constantly purchasing items at the game’s onset.  If I were to give him my ghetto paper game without the real iPad game, there would be no doubt he’d be bored in a day.  

In the Post-PC World our children are learning on tablet devices.  You can either shake your head and say “when I was a kid, we learned by…” or you can embrace and extend their experiences.  Either way, they’ll be playing with your iPad.

Amazon’s SimpleDB in action

Amazon’s SimpleDB is a NoSQL database service.  Just like the name, it’s very simple which makes it very easy to use but it has its limitations.  The key things to remember are:

• no joins
• one item can have two or more values for the same attribute
• everything is a string with maximum length being 1024 characters
• select statements are “SQL like” but not completely compatible
• db does not auto generate primary keys

 There are many NoSQL open source projects one can download and install but the attractiveness of SimpleDB is that it’s a database service Amazon hosts for you. You don’t have to worry about installation and administration of a NoSQL database.

To show SimpleDB’s feature set in action, let’s create a quick and dirty project that stores notes.  I’m going with the route of using the command line and vim so you can quickly get this project up and running.  Using Amazon’s Eclipse plugin will be a more intuitive way for you to create a project.: (You also need an AWS account and have agreed to the SimpleDB TOS)

1) Create a project using maven from the command line.  This will create a Java project that will generate a JAR along with standard directories and a standard project file.

2) Add the AWS Java library to the pom.xml file generated by Maven to make the SimpleDB calls.  Maven will download the AWS SimpleDB JAR library for you and include it in the classpath when building.
3) Write the Note class.  A Note consists of a timestamp which is also the primary key, a description that contains a text note, and an integer priority with 1 being the most important and 5 being the least.  

The “Note(Item item)” constructor takes in an Item from SimpleDB and populates the member variables.  The loop seems unnecessary until you see that the API Amazon provides has no way of retrieving attributes from their names.  Amazon really tried to keep the API lite and my feeling is that Amazon wants the API user to realize that the database returns attributes in a random order, so buyer beware.

The “getAttributes” method creates an array of attributes to be populated to the database.  The priority field needs to be padded with zeros so that select statements with order can be made.  As noted above, everything is a String in SimpleDB so the zero pad is a workaround.  Also note, that the boolean “true” states that the attribute’s value can overwrite what currently exists.  If “false” is provided instead, then the attribute can have multiple values.

4) Write the NoteMaker class.  You’ll need to replace the “AWS_” keys with your own.  Things to note are:

• createDomain call did not require a schema.  After the table is made, you’re free to insert items with as many and as few attributes that you want
• the PutAttributeRequest really highlights what SimpleDB is - a key/value store.  Store these attributes to this primary key.
• the selClause looks very much like a SQL statement

5) Write the NoteMakerTest class

6) Run the test

7) Create an Eclipse project

This is a very simple intro to SimpleDB. In a future post, I’ll give Google’s App Engine datastore a similar treatment.

To get a better understanding of the limitations of S3, read Netflix’s transition to NoSQL

How “Transparent Scalability” Makes Small Business Look Really Big

How can a company like Dropbox jump from serving 5 million users to 25 million users in one year and only increase its employee base from 30 to 60 people?  Even more astonishing, how can they keep their costs so low that they haven’t had to raise more than $7.2 million to fund the company.  Roughly speaking, assuming one server can handle the load of 1000 simultaneous users and at peak usage there are 15 million simultaneous users then Dropbox would require 15,000,000/1000 = 15,000 servers.  If each server costs $500 then just the procurement of the servers will cost 15,000 * $500 = $7.5 million.  This is just for the procurement of the hardware.  Add in the installation, administration, and maintenance of the hardware and you can easily triple or quadruple that amount to $20-30 million.  So how does a small little 60 person Startup handle a major fixed cost like this?  Don’t buy the servers.  Rent them. This is the largest reason why Startups are scaling their user base so quickly without having to raise a tonne of money.  Dropbox treats server expense as a variable cost and rents its hardware on demand from Amazon’s cloud infrastructure AWS. Assuming that the average number of servers Dropbox requires is 5000 servers (during non peak hours, Dropbox rents fewer servers so the average number goes way down) and each server costs $60/month to run then DropBox’s yearly bill for renting hardware is 5000 * $60/month = $300,000/month * 12months/year = $3.6 million.  So by not having to own servers Dropbox has been able to reduce their hardware costs by a factor of 10.  

Transparent scalability is when you can serve more and more customers and not have to worry about infrastructure and logistical costs of running your business.  In most businesses there is a point of diminishing returns.  For instance, if I ran a popular nightclub I’d try to pack as many customers as I can into the space.  However, there comes a point where I’ve packed so many people in, that everyone in the night club is no longer having a good time and they stop drinking and start leaving.  As the business owner, I’m then faced with the tough decision of whether to move to a larger building to handle more customers, or stay in the current building and make more from my current customers.  Transparent scalability solves this problem for the business owner, and it’s a wonderful thing.  Suddenly, the night club owner realizes his land lord owns the whole block of buildings surrounding his nightclub, and the land lord can turn any of those buildings into a night club in 10 minutes, and the rental fee is ridiculously affordable and by the hour.  It’s a dream every brick and mortar business wishes he had.  It’s a reality every software Startup is equipped with.

As the cloud infrastructure purveyors such as Amazon’s AWS and Google’s App Engine gain more experience at being server landlords they are making it easier and easier for Startups to not have to think about scalability.  Amazon’s Beanstalk and Google’s App Engine allow businesses to transparently scale load.  While Amazon’s SimpleDB and Google’s App Engine datastore allow businesses to transparently scale data.  

If 90% of Dropbox’s customers moved to another service this instant, Dropbox could, within the hour, reduce by 90% it’s server usage from Amazon.  Even with 10% of its existing users they’d be able to maintain payroll for their 60 employees.  What other type of business can see a 90% drop in revenue and not have to lay off employees?

Yes, I’m a nerd.  ”Transparent Scalability” are my two favorite words.  (Don’t tell my wife)

An iOS Map App, with Points of Interest, in < 1 KLOC

How hard would it be to write an iOS app that displayed stores, restaurants, and other points of interest around you?  It turns out, you can do this very easily using the Factual iOS SDK client.  What is Factual?  Factual is a big data store of facts, with one of the biggest being a huge points of interest database.  I’ve wrote a simple Universal iOS project that displays points of interest around your current location.

 

iPad version

 

iPhone version
 

In the initializing method, viewDidLoad, the iOS location manager is started and asked for an update of the device’s current location. When the coordinates have been found, the callback method, didUpdateToLocation, is called and the map is initialized to show an area of 1/3 mile radius around the current location. The addPoints method is then called to retrieve and mark points of interest.


In the addPoints method, the Factual API is called with the coordinates of the current location and is asked to find points of interest within a ⅓ mile radius of those coordinates.  In the requestComplete callback method, the Factual API table results are returned and markers are populated onto the map.

This is a simple demo of an iOS map app in less than 1000 lines. In future posts I’ll add other features such as having points of interest dynamically change when the map shifts, being able to tap on a phone number to place a call, and having an opinion layer on top of the data layer to display ratings for the POI.  Please let me know if you have other suggestions.

5 Tips for integrating Google Analytics for Mobile

Google Analytics is a great tool for capturing and reporting aggregate metrics for web applications.  By including a small code snippet in your web pages, Google Analytics captures and stores all the web pages visited by your users for free.  When you log into Google Analytics you’re presented with a clean dashboard with the most relevant information including number of page views, visits, average time on site, etc. and an interactive graph to visualize the data in different ways.  For example, here is the dashboard of a Google Gadget I developed and have tracked using Google Analytics.  (It’s a simple spellchecker/dictionary/encyclopedia UI over Wikipedia data)
 

 
By browsing the subsections on the left navigation bar, you can drill down deeper to discover metrics such as:
 
1) How many of your users are new vs returning?
2) What is the breakdown of browser, OS, and screen resolutions of your users?
3) Where are you getting your traffic from?
4) What are your most popular pages?
5) What are the pages your users typically exit from?
6) and lots more

For mobile developers looking to capture metrics like web pages, Google Analytics offers SDKs, Google Analytics for Mobile, to capture metrics for your mobile app as if it were a webapp.

To start the process of tracking your mobile app, create a new profile in your Analytics launch page.



Tip 1: Use a systematic subdomain naming system for your profile name.

Google Analytics requires you to name your mobile app to be tracked with a domain.  If you’re app is called FooBar, don’t register the name to be foobar.com because you’ll probably want to run Google Analytics on the website one day which should use that name.  Use something like app.mobile.foobar.com as the name (mobile.foobar.com could be used for the mobile version of your web site).  If for some reason you want to track apps from different platforms using different Google Analytics profiles, use something like ios.mobile.foobar.com and android.mobile.foobar.com


Tip 2: Track screens the user sees as pages and things that happen within a screen as events.

Google Analytics has the notion of pages and events.  Pages are web pages a user clicks a link to get to, and events are interactive actions that happen within a page, usually triggered by Javascript AJAX calls.  To map this concept to a mobile app, you should track unique screens as the pages and anything that happens within a screen as an event.  For instance, in an email application, you would track opening an email message as a page view and flagging or favoriting that email as an event.

In this example dashboard, you can see that the different “top pages” represent different screens of the application.  The iPhone main screen, page1 of a Skunk book, etc.  BookPlayground is a BookStore app I developed that has a collection of interactive children’s books.  



Tip 3: Use a systematic directory naming scheme for pages and events

Google’s event capturing feature set is a useful tool but the flexibility they’ve incorporated in the API makes it very difficult to generate useful reports unless you have a systematic way of naming the event variables.  When a screen is represented as a page, and you see a list of “top pages”, it makes perfect sense to see a report that lists your app’s most popular screens.  Google named their event tracking API with category, action, label, and value, and offer very few best practices or use case scenarios for you to review.  The following system has worked for me in the past.  

1) Use a URI naming scheme, with category being the page the event occurred.
e.g.
/iPhone/email_list/page/1
/iPhone/email_details/

This way, you have a way to track which screen the events are happening on

2) Append the category to an action.  
e.g.
/iPhone/email_details/delete
/iPhone/email_details/flag

In the current version of Google Analytics (June 20, 2011), there’s no way to generate a report that ties actions to categories.  As a workaround, I include the category in the action name using the same URI naming scheme.  In cases where you want to track actions that go beyond a single page, come up with a system wide URI name.
e.g.
/iPhone/global/uh_oh_device_being_shaked

I’m very curious how other mobile developers are tracking events so please email me any of your ideas.

Tip 4: Keep a spreadsheet as a reference

Keep a record of how you’re tracking your pages and events.  It’s important to name your pages and events with an extensible standard early because once you’ve started logging, if you come up with a new naming scheme, you won’t be able to link up the old logs to your new logs.  I suggest creating a Google Docs spreadsheet that you share with developers and report viewers.  Create two tabs: “pages”, and “events”.  List the options for the naming of a page, examples of each different type of page that can be tracked, and a description of what you’re tracking.  I like Google Docs because it’s a very lightweight way to create a single point of reference for metrics data.  The lighter the weight, the more it’ll be used.

Tip 5: Track errors and performance

I know what you’re thinking.  This belongs in system logs and not in the user analytics system.  My rebuttal is, “are actual users being affected by errors and performance issues” in your app.  If they are, then they should be tracked here along with the system logs.  Errors and performance issues affect the happiness of your users and how well you can retain them.  The redundancy is worth it.  

I track errors like this: action
/iPhone/email_details/email_id/aidfn3234/load_failure

and performance issues likes this: action + value (in ms)
label: /iPhone/email_details/load_email value: 1500

Please let me know what mobile analytics suggestions or obstacles you’ve run into and I’ll add them to a follow-on post with more sample code.

HTML5 vs Native

Tim Bray recently wrote a good article titled “Web” vs “Native”.  He starts off by saying the debate shouldn’t be labeled “Web” vs “Native”.  Any connected “Native” app that makes http calls is a “Web” application.  (e.g. App Store, IMDB, Pandora, Maps, etc.)  I agree with this point and think the debate should be framed “HTML5” vs “Native”.  
 
The language used to code the majority of mobile applications will determine the ecosystem that will prevail.  Currently, that’s native code, meaning you’re writing Objective-C in XCode for iOS and Java in Eclipse for Android.  If you need to support the other mobile platforms, then going “Native” truly becomes a nightmare because you need to spread your development resources very thin to handle the breadth of native code you need to write and iterating your product becomes a time suck because you’ve just multiplied your code base by the number of platforms you need to support with very little reusable client code.

Whenever Steve Jobs announces the next iPhone, it’s like the starting gun has been fired for a new race to build the next Killer App to get into the App Store before the next wave of buzz and euphoria.  To do this, you need to race with tens of thousands of other developers to reach the promised land of “Top 50” Apps.  The earlier you get on the list, the quicker users will want to try your app and keep you longer on the “Top 50” list.  How are you going to do that if you’re just not shipping fast enough?

 
HTML5, on the other hand, is said to be the true promised land.  HTML5 is the next evolution of the web page standard to incorporate “Native” application behaviour to websites.  HTML5 apps can store files locally on your computer, work offline, know your location, run multiple actions at the same time, display video without Flash, display graphics better, and do a few other things that make web pages look less static and act more dynamic.  The great thing is that all major PC and mobile browsers will support the HTML5 standard.  This theoretically means you write two HTML5 versions of your app, one for desktop browsers and one for mobile browsers.  The two versions will be able to share some code and will work on the majority of mediums your users are on. Beautiful dream, and by and large, I think this will happen but the rollout will not be as clean and dreamy as the HTML5 purists have in mind.  

What will push HTML5 apps forward is the decision of the Android architects to support multiple resolutions on the Android platform.  Every mobile development shop I’ve spoken to has or had an iOS project that required porting to the Android platform and not one has had a good experience doing the port.  The challenge is, UI designers for iOS often used fixed positioned layouts for their aesthetic designs.  On iOS, this is not an issue because you essentially only need to design for two screen resolutions: iPad’s 1024x768 and iPhone 4’s 960x640.  (For older phones, UI designers scale down the retina images to half size, so 480x320 is not an issue)  UI designers love fixed layouts because they have complete control over the screen’s real estate.  Asking a UI designer to design for iOS is like asking a fashion designer to create a custom shirt or dress for you.  Now you ask the same UI designer to do the same for Android and it’s like designing for you, your younger brother, and your older brother.  On iOS you get couture.  On Android, you get a hockey jersey; it conveys the message, allows for stretching, but it ain’t pretty.  In more concrete terms, the iOS UI will have a customized, polished interface while the Android UI will look like a website, with headers, footers, menubars, and buttons all designed to stretch.  Business stakeholders that pay for these Android development resources will not see the cost benefit of coding a UI in native Android when it looks and works the same as an HTML5 app.  This will start the train for HTML5 apps.     

First, they’ll appear as HTML5 hybrid apps produced with a tool such as PhoneGap. Hybrid apps contain standardized HTML5 code whenever possible, but have non standardized javascript APIs that tap into the native platform’s device capabilities.  The major benefit of hybrid apps is that they can be packaged to be delivered to all the major mobile App Stores.  This offers mobile developers two ways to distribute their HTML5 apps: through an App Store and through the browser.
 
Second, there will be one or two dominant libraries/SDKs developers will use to build HTML5 apps, because hand tweaking HTML5 code for every variant of browser is currently too laborious a task.  JQuery and Sencha are the two dominant client side libraries that could be the go to library for HTML5 apps.  I’m personally rooting for GWT by Google because it’s integrated with Eclipse, it’s a proven SDK used by the GMail team, and the Java abstraction that outputs unique code to the different browsers is a very innovative idea and I think has a lot of legs.  Why the GWT team hasn’t already created a set of mobile UI class libraries I don’t understand?  It’s a major opportunity in the mobile HTML5 library/SDK space.  If someone knows about an open source effort to create a mobile UI class library for GWT, please email me!

So there it is. My prediction is that mobile shops will still code native for iOS because native apps will still look, work, and feel better than HTML5 apps, and all other mobile platforms: Android, Windows Phone, BlackBerry, etc will see HTML5 apps emerge.

Why iCloud Matters

There are blog entries such as this and this that claim that iCloud is not a revolutionary product.  They claim that Google got there first with the Docs apps or that the only way for iCloud to be effective is if you live within Apple’s walled garden and use their devices.  Both statements are true.  However, I’d argue that a revolution is not when you are the first to invent an idea adopted by a minority, a revolution is when you are the first to spread an idea adopted by the majority.  Apple’s genius isn’t the first to innovate in a new market, it’s genius is being the first to cross the chasm with products loved by the masses and not just by the early adopters.  Apple does this with an incredible user experience that the other cloud providers can’t match.  
 

 
What makes iCloud a better user experience than Google’s bevy of Android apps connected to Google’s cloud?  iCloud will offer an incredible offline experience.  Firstly, Data is pushed to the client making response times for local apps appear instantaneous.  For example, flicking through a gallery of images already pushed onto a device will appear a magnitude faster than downloading the same images from the cloud on the fly.  Secondly, disconnected apps will work.  If you have a bad network provider such as ATT and lose connection to the Internet, you will not be able to use the Google Docs app because Google’s cloud will be inaccessible.  In the iOS world, the data would have been pushed to your device before ATT lost your Internet connection, making it possible for you to work with that document.  Lastly, Apple has opened the iCloud platform to developers to create apps that sync the way Apple’s apps do.  You’ll create apps that work seamlessly for your users and Apple will validate that experience before it’s released to the App Store.

Consumers are very comfortable with cloud pushed text messages and notifications.  By only requiring users to log in once to their device, and having iCloud “just work”, Apple has crossed the chasm and will bring cloud pushed documents, photos, songs, and videos to the masses.  Developers will be pushing even more possibilities.  People will love iCloud and not know why.  Isn’t it true love when you can’t explain why you love something?

Hello World!

I’m Ivar, a mobile Product Manager living in Los Angeles, and this is my blog on technology.  My interests are mainly focused on mobile and cloud computing and most of the blog entries will be my thoughts on technology or small programming projects. Sample code and projects will be open sourced under Apache.  Happy Hacking!