The Copycat View Application

We all know how tempting it can be to copy our view code in each view instance. We want to provide our user base with as much functionality (and as many different views) as possible without expending a lot of engineering resources. Cloning that view for every portal that’s visible to the user can seem like a no-brainer at times.

The simple fact is that users will see right through this technique, and will view your application poorly, if they switch between a small view and a large view only to be presented with exactly the same thing they just saw. This can create a lack of trust once the users see something amiss in the application. After all, if the developer has not put in the time and effort to fully build out the application, how can they trust that application with their social information?

Let’s explore the trust relationship of this scenario first. If you’re building an application that will attempt to either monetize the user experience or drive traffic back to a source, the last thing you want is for a user not to trust that application. When a user actively migrates to a different view and is presented with the same screen and functionality that he just saw, he will believe there’s something wrong with the application—something happened that shouldn’t have. He’ll remember this when you try to monetize that experience. Essentially, you’re establishing a trust relationship in order to get some sort of return on investment from your users.

Next, ...

Get Programming Social Applications now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.