I’ve mentioned the fact that having relevant small views can help to promote user growth and engagement, but the same is also true for the larger views. Some development shops wish to work only with the larger views; likewise, some want to work only with the small views since that is the first thing the user sees in most circumstances.

Let’s look at an application’s small views first. We’ve already talked about how some containers impose restrictions on the small view that may prevent JavaScript and Flash integration, and these restrictions are usually the chief reason why developers don’t develop a rich and compelling small view. Since it is the user’s first interaction with your application, a compelling small view will promote application growth. Once the user has been regularly interacting with your application, you should change the small view to incentivize him to continue on to the large view. For a game, this incentive might be current statistics, stats of friends for comparison, or new items that the user can earn by performing some action. For productivity applications, it might include reminders for upcoming tasks, a comparison of his actions against those of his friends, or some simple functionality for interacting with the application.

Moving on to the large view, the main reason why some developers don’t develop this view is that they create applications containing functionality that’s so simple it is not impeded by any small view restrictions. This is a very shallow way to think about a social application and basically means that you don’t think your users will need or want any further functionality other than the basic data you’re providing. Most containers do not offer a way to turn off a view, so they show a blank page for views that are not defined. This means that the developer has to go through the task of attempting to hide the means for users to switch between views, which may actually require some development effort, depending on how containers have implemented their view-switching mechanisms. The bottom line is that such a developer basically restricts users to views that are smaller and contain fewer features because she doesn’t want to make the effort to build a compelling application that leverages the container’s existing features.

Users quickly catch on to applications that try to deliver them content without any extensive depth or those that expect them to use the application from only a single place.