When we pay for software, it’s usually because it solves a critical problem we have. It satisfies a need. It provides a certain value we’re willing to pay for.

And if we can derive value from a product or a service at no upfront cost, then we are more likely to pay later on in order to continue deriving that value.

Internet entrepreneurs need a business model that supports this notion.

The Problem with Existing Business Models

There seems to be three popular business models for an Internet software as a service (SaaS) company:

1. Freemium: Have a free subscription plan and paid subscription plans that have more features than the free plan
2. Free trial: Have a free trial period and then charge customers after the period is over
3. Paywall: In order to use the service, a user will have to pay first

Issues with Freemium

The freemium model is full of flaws. Paul Sawers, an editor at Internet technology news site The Next Web, explains why freemium doesn’t work:

"People are simply too accustomed to consuming content for free, and many businesses will find it tricky converting users from the free version of a service to the paid one. Even in the more successful cases, the non-paying users will typically always outnumber the paying users, the upshot of this being a company is dedicating time, money and resources to supporting users that have absolutely no intention of coughing up cash."

Mark Evans, a consultant to startups, says this about the freemium business model:

"The problem is freemium doesn’t work for the vast majority of companies, especially ones focused on the consumer market. In theory, it sounds good but in practice few people actually pay for more features. Sure, there are exceptions to the rule but those are few and far between."

"Freemium is flawed because most people don’t need more features than what they can use for free."

Issues with Free Trials

Right now, the typical paid app will offer a trial so that users can try before they buy. The trial period is usually time-based: 7 days, 14 days, 30 days.

The problem with this approach is that this time-based limit is not user-centered. App developers opt for it because they want to generate revenue as quickly as possible.

But how do you know that the user has received any or enough value from the product in that period? Usually, you don’t.

What happens when the user hasn’t had enough time to receive enough value? They won’t become paid users.

Issues with Paywalls

Internet users are generally unwilling to pay for a service without being able to try it first. This is the reason why the freemium and "free trial" business models above became common.

And if you’re in a competitive space, chances are good that your competition is offering some form of free access to their product, which reduces the likelihood of potential users trying yours when they see their other free options.

What Should We Do Instead?

Our best bet is to use a business model that converts non-paying users to paying customers at the right time. That time is when they have already received significant value from our product.

The premise is this: Users will want to pay for the product because they have the desire to continue receiving the value they’re getting.

Value Activation Metrics

We can activate the payment once the user has derived significant value from our product.

We can ask users to pay at the point when the product has solved a specific problem that they would like to keep solving. We can pick certain "value activation" metrics to determine what point we should ask users to start paying.

I define the term value activation metric as a quantifiable measurement that is specific to an app. It’s a signal that tells us the user is now getting significant value from the product and that he/she is now likely willing to start paying for it.

Examples of value activation metrics include:

• Number of sales leads the user gets
• Number of royalty-free stock photos downloaded
• Number of invoices sent to the user’s paying clients
• Amount of site traffic the user has gotten from your services
• Amount of disk storage used

Dave Gooden, founder of LakePlace (a site that enables people to rent out their lakefront property) explains the approach he took with his users:

"We noticed our visitors asking our listing agents if any of their listings were available for rent. After the 100th (or 500th) request, we decided to open up a vacation rental marketplace. Using what we learned the first time around, we got back on the phones and offered resort owners and vacation rental managers free trials. We went as far as inputting all of their information, uploading their pictures, etc… whatever it took to get them to try LakePlace.com. Once they received 10-20 inquiries, we let them know that the free trial was over and it was time to become a paying customer. I think we had a 99% retention rate when converting free trial users to paying customers. Today, LakePlace.com’s Minnesota vacation rental section is about the same size as Homeaway & VRBO…and waay bigger than AirBnB’s…and we are a very close 2nd in Wisconsin (I hope to fix that this year)."

In this scenario, the value activation metric is the number of inquiries. Once resort owners and vacation rental managers received 10-20 inquiries worth of value, to continue to receive the value of the service, they needed to pay.

Gooden knew that once a user had received a certain amount of inquiries, the user was likely making money from those inquiries and thus had activated the value of his service.

Also note the high conversion rate in Gooden’s account: 99% retention rate, which — even if it might just be a figurative number that he used to convey a significantly high conversion rate — is a statement of his strategy’s efficacy.

A few companies understand this concept of activating the value of a product before charging for their service. Dropbox and Evernote are two.

Dropbox users get peace of mind knowing that they will always have access to their files. The more files someone stores, the more likely they will run out of space, and the more likely they will convert to a paid user.

Once the user has gotten enough value from using Dropbox, they are more likely to pay in order to keep using the service.

Evernote knows that the longer you remain a customer, the more likely you will convert to a paid user. In fact, it has a pretty good idea of when you will do so. The value of Evernote is in enabling users to store and retrieve any memory easily.

So, to store a memory, users simply snap a picture and upload it to Evernote. The software indexes the picture, and users can even search for words in the picture.

It stands to reason, then, that the more users store, the more valuable the service becomes. And at a certain point, the user becomes willing to pay to continue deriving that value from using Evernote.

When building an Internet-based service or product, we should start examining the points in which the user starts getting significant value from it.

How many sales leads does a user need to get, in order for her to want to pay to continue getting those sales leads?

How much data will a person need to store before he sees how important it is to have a cloud backup of his files that’s accessible on all his Internet-enabled devices?

Once you figure out what value activation metrics are appropriate for measuring the value you provide your users, you can use them to signal the point in which you should convert non-paying users to paying customers.

Related Content

• 5 Pricing Tips to Earn More on Client Projects
• 7 Tips for Giving Effective Design Project Quotes
• 7 Pricing Strategies Based on Research Studies
• Building Mobile Web Apps the Right Way: Tips and Techniques
• Designing Pricing Plans for Subscription-Based Web Apps
• 10 Excellent Online Payment Systems
• Related categories: Business and Web Apps

About the Author

Marc Gayle is a Rails developer and founder of 5KMVP, where he builds Minimum Viable Products for just $5K. Follow him on Twitter and check out his personal blog.

The post Value Activation: A Different Business Model for Internet Entrepreneurs appeared first on Six Revisions.

Design and development community, Forrst, has announced a completely new and improved website experience.

Originally created by Kyle Bragger, the site was acquired by Zurb at the beginning of this year and the company has wasted no time building on and improving Forrst’s unique social feedback systems.

Forrst is similar to sites like Dribbble, which allow designers to post ideas and ask for feedback. What makes it stand out is that, in addition to visual concepts, members can also post code. A less tangible, but probably more important difference is the site’s commitment to facilitating detailed feedback and fostering an active community of web design and development peers.

Zurb has been transparent about their ideas for Forrst, posting plans for site updates and new features on their blog. About a month ago, they began a private release to iron out final details before making the changes public.

To make good on their promise to “turn Forrst into a place of active learning so that Forrsters can get actionable and contextual feedback,” the team has introduced:

• annotations (incorporating Notable, Zurb’s own feedback app);
• a new, less vertical design for the site;
• mobile-first functionality.

Annotations allow members to give detailed contextual feedback by highlighting areas of a post and adding sticky-like notes. For now, annotations can only be added from a desktop browser, but you will be able to read them from your mobile device.

The focus of the site design changes has been improving readability and discovery of posts. If you’re a longtime Forrst member, you’ll see the difference as soon as you land.

The mobile-first functionality is off to a good start, relying on Zurb’s existing Foundation 4 framework. At the moment, this means members can browse posts and leave feedback from just about anywhere.

More features are in the pipeline, including increased functionality for annotations, a re-think of the Forrst Leaderboard and a significant update to perks for Pro supporters.

If you are new to Forrst, you can sign up as a Scout. You become a full-fledged member once a Forrster has voted you in.

Do you use Forrst? Is Zurb acquiring Forrst a positive move for the community? Let us know in the comments.

MacDojo’s Mac Shortcuts Pro Course – only $27!

Welcome to the second part of my IndexedDB article. I strongly recommend reading the first article in this series, as I’ll be assuming you are familiar with all the concepts covered so far. In this article, we’re going to wrap up the CRUD aspects we didn’t finish before (specifically updating and deleting content), and then demonstrate a real world application that we will use to demonstrate other concepts in the final article.

Updating Records

Let’s start off by discussing how to update a record with IndexedDB. If you remember, adding data was pretty simple:

//Define a person
    var person = {
        name:name,
        email:email,
        created:new Date()
    }
    
    //Perform the add
    var request = store.add(person);
    

Updating a record is just as simple. Assuming that you have defined a property called id as your key for your object store, you can simply use the put method instead of add.

var person = {
        name:name,
        email:email,
        created:new Date(),
        id:someId
    }
    
    //Perform the update
    var request = store.put(person);
    

Like the add method, you can assign methods to handle the asynchronous results of the operation.

Deleting Records

Deleting records is done via the delete method. (Big surprise there.) You simply pass in the unique identifer of the record you want to remove. Here is a simple example:

var t = db.transaction(["people"], "readwrite");
    var request = t.objectStore("people").delete(thisId);
    

And like every other aspect of IndexedDB, you can add your handles for the asynchronous results.

So, as I said, not terribly exciting, which is probably good. You want your APIs simple, boring, and unsurprising. Now let’s take what we’ve learned and bring it together to create a real, if simple, application.

The Note App

Ok, finally we have all (well, most) of the parts we need to build a real application. Since it hasn’t been done before (ahem), we are going to build a simple note taking application. Let’s look at a few screen shots and then I’ll show you the code behind it. On launch, the application initializes an IndexedDB for the application and renders an empty table. Initially, all you can do with the application is add a new note. (We could make this a bit more user friendly perhaps.)

Clicking the Add Note button opens a form:

After entering some data in the form, you can then save the note:

As you can see, you have the option to edit and delete notes. Finally, if you click the row itself, you can read the note:

So not exactly rocket science, but a full working example of the IndexedDB specification. The notes written here will persist. You can close your browser, restart your machine, take a few years off to contemplate life and poetry, and when you open the browser again your data will still be there. Let’s take a look at the code now.

First – a disclaimer. This application would have been a perfect candidate for one of the many JavaScript frameworks. I’m sure those of you who use Backbone or Angular can already imagine how you would set this up. However – I made the bold decision here to not use a framework. I was worried both about the people who may use a different framework and those who use none. I wanted our focus here to be on the IndexedDB aspects alone. I fully expect some people to disagree with that decision, but let’s hash it out in the comments.

Our first template is the HTML file. We’ve only got one and most of it is boilerplate Bootstrap:

<!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
    
        <title>Note Database</title>
    
        <link href="bootstrap/css/bootstrap.css" rel="stylesheet">
        <link href="css/app.css" rel="stylesheet">
    
      </head>
    
      <body>
    
        <div class="navbar navbar-inverse navbar-fixed-top">
          <div class="container">
            <div class="navbar-header">
              <a class="navbar-brand" href="#">Note Database</a>
            </div>
          </div>
        </div>
    
        <div class="container">
    
            <div id="noteList"></div>
            <div class="pull-right"><button id="addNoteButton" class="btn btn-success">Add Note</button></div>
            <div id="noteDetail"></div>
    
            <div id="noteForm">
                <h2>Edit Note</h2>
                <form role="form" class="form-horizontal">
                <input type="hidden" id="key">
                <div class="form-group">
                    <label for="title" class="col-lg-2 control-label">Title</label>
                    <div class="col-lg-10">
                    <input type="text" id="title" required class="form-control">
                    </div>
                </div>
                <div class="form-group">
                    <label for="body" class="col-lg-2 control-label">Body</label>   
                    <div class="col-lg-10">
                    <textarea id="body" required class="form-control"></textarea>
                    </div>
                </div>
                <div class="form-group">
                    <div class="col-lg-offset-2 col-lg-10">
                        <button id="saveNoteButton" class="btn btn-default">Save Note</button>
                    </div>
                </div>
                </form>
            </div>
    
        </div>
    
        <script src="js/jquery-2.0.0.min.js"></script>
        <script src="bootstrap/js/bootstrap.min.js"></script>
        <script src="js/app.js"></script>
      </body>
    </html>
    

As mentioned above, a good size portion of this file is template code for Bootstrap. The parts we care about are the noteList div, the noteDetail div, and the noteForm. You can probably guess that these are the DIVs we’ll be updating as the user clicks around in the application.

Coding Our Core App File

Now let’s take a look at app.js, the core file that handles the logic for our application.

/* global console,$,document,window,alert */
    var db;
    
    function dtFormat(input) {
        if(!input) return "";
        var res = (input.getMonth()+1) + "/" + input.getDate() + "/" + input.getFullYear() + " ";
        var hour = input.getHours();
        var ampm = "AM";
        if(hour === 12) ampm = "PM";
        if(hour > 12){
            hour-=12;
            ampm = "PM";
        }
        var minute = input.getMinutes()+1;
        if(minute < 10) minute = "0" + minute;
        res += hour + ":" + minute + " " + ampm;
        return res;
    }
    

You can ignore the first function as it is simply a format utility for dates. Let’s skip ahead to the jQuery document ready block.

Checking for Browser Support

$(document).ready(function() {
    
        if(!("indexedDB" in window)) {
            alert("IndexedDB support required for this demo!");
            return;
        }
    
        var $noteDetail = $("#noteDetail");
        var $noteForm = $("#noteForm");
    
        var openRequest = window.indexedDB.open("nettuts_notes_1",1);
    
        openRequest.onerror = function(e) {
            console.log("Error opening db");
            console.dir(e);
        };
    
        openRequest.onupgradeneeded = function(e) {
    
            var thisDb = e.target.result;
            var objectStore;
    
            //Create Note OS
            if(!thisDb.objectStoreNames.contains("note")) {
                console.log("I need to make the note objectstore");
                objectStore = thisDb.createObjectStore("note", { keyPath: "id", autoIncrement:true });  
            }
    
        };
    
        openRequest.onsuccess = function(e) {
            db = e.target.result;
    
            db.onerror = function(event) {
              // Generic error handler for all errors targeted at this database's
              // requests!
              alert("Database error: " + event.target.errorCode);
              console.dir(event.target);
            };
    
            displayNotes();
    
        };
    

Our very first action is to check for IndexedDB support. If the user’s browser isn’t compatible, we use an alert and abort the function. It would probably be better to relocate them to a page that fully explains why they can’t use the application. (And to be clear, we could also build an application that made use of WebSQL as a backup. But again – my focus here is on simplicity.)

After caching a few jQuery selectors, that we’ll use throughout the app, we then open up our IndexedDB database. The database is fairly simple. In the onupgradeneeded handler you can see one object store called notes being created. Once everything is done, the onsuccess handler will fire off a call to displayNotes.

The displayNotes Function

    function displayNotes() {
    
            var transaction = db.transaction(["note"], "readonly");  
            var content="<table class='table table-bordered table-striped'><thead><tr><th>Title</th><th>Updated</th><th>&amp;nbsp;</td></thead><tbody>";
    
            transaction.oncomplete = function(event) {
                $("#noteList").html(content);
            };
    
            var handleResult = function(event) {  
              var cursor = event.target.result;  
              if (cursor) {  
                content += "<tr data-key=\""+cursor.key+"\"><td class=\"notetitle\">"+cursor.value.title+"</td>";
                content += "<td>"+dtFormat(cursor.value.updated)+"</td>";
    
                content += "<td><a class=\"btn btn-primary edit\">Edit</a> <a class=\"btn btn-danger delete\">Delete</a></td>";
                content +="</tr>";
                cursor.continue();  
              }  
              else {  
                content += "</tbody></table>";
              }  
            };
    
            var objectStore = transaction.objectStore("note");
    
            objectStore.openCursor().onsuccess = handleResult;
    
        }
    

The displayNotes function does what you expect – get all the data and display it. We discussed how to get all rows of data in the previous entry, but I want to point out something slightly different about this example. Note that we have a new event handler, oncomplete, that we’ve tied to the transaction itself. Previously, we’ve used events just within the actions, inside the transaction, but IndexedDB lets us do it at the top level as well. This becomes especially useful in a case like this. We have a giant string, our HTML table, that we build up over each iteration of our data. We can use the transaction’s oncomplete handler to wrap up the display portion and write it out using a simple jQuery call.

The Delete, Edit, and Add Functions

    $("#noteList").on("click", "a.delete", function(e) {
            var thisId = $(this).parent().parent().data("key");
    
            var t = db.transaction(["note"], "readwrite");
            var request = t.objectStore("note").delete(thisId);
            t.oncomplete = function(event) {
                displayNotes();
                $noteDetail.hide();
                $noteForm.hide();
            };
            return false;
        });
    
        $("#noteList").on("click", "a.edit", function(e) {
            var thisId = $(this).parent().parent().data("key");
    
            var request = db.transaction(["note"], "readwrite")  
                            .objectStore("note")  
                            .get(thisId);  
            request.onsuccess = function(event) {  
                var note = request.result;
                $("#key").val(note.id);
                $("#title").val(note.title);
                $("#body").val(note.body);
                $noteDetail.hide();
                $noteForm.show();
            };
    
            return false;
        });
    
        $("#noteList").on("click", "td", function() {
            var thisId = $(this).parent().data("key");
            var transaction = db.transaction(["note"]);  
            var objectStore = transaction.objectStore("note");  
            var request = objectStore.get(thisId);
    
            request.onsuccess = function(event) {  
                var note = request.result;
                $noteDetail.html("<h2>"+note.title+"</h2><p>"+note.body+"</p>").show();
                $noteForm.hide();
            };  
        });
    
        $("#addNoteButton").on("click", function(e) {
            $("#title").val("");
            $("#body").val("");
            $("#key").val("");
            $noteDetail.hide();
            $noteForm.show();       
        });
    

Our next two methods (delete and edit) is another example of this same principal. Since none of the IndexedDB calls here are new, we won’t bother going over them. Most of the “meat” here ends up being simple DOM manipulation to handle the particular actions. The handler for clicking the add button is exactly that, so we’ll skip over that as well.

The Save Function

    $("#saveNoteButton").on("click",function() {
    
            var title = $("#title").val();
            var body = $("#body").val();
            var key = $("#key").val();
    
            var t = db.transaction(["note"], "readwrite");
    
            if(key === "") {
                t.objectStore("note")
                                .add({title:title,body:body,updated:new Date()});
            } else {
                t.objectStore("note")
                                .put({title:title,body:body,updated:new Date(),id:Number(key)});
            }
    
            t.oncomplete = function(event) {
                $("#key").val("");
                $("#title").val("");
                $("#body").val("");
                displayNotes();
                $noteForm.hide();           
            };
    
            return false;
        });
    
    });
    

The next interesting tidbit is the save method. It has to use a bit of logic to determine if we are adding or updating, but even that is rather simple. And that’s it! A complete, if simple, IndexedDB application. You can play around with this demo yourself by downloading the attached source code.

In Conclusion

That’s it for part two! The third article will take this application and begin adding additional features including search and array based properties.

As many of you know, UMBC has had a large number of phishing attacks in the past few weeks.  This has resulted in a number of compromised accounts which the attackers are using to setup fake web pages and send out large volumes of spam.  In an attempt to better protect accounts from fake web pages, DoIT will be removing permissions from user AFS web volumes for accounts not currently using their web space (http://userpages.umbc.edu/~username).  

This will not affect anyone who currently has a web page or stop anyone from creating a web page, but will stop automated attacks and make it more difficult for attackers to setup web pages on people’s accounts.  The permission change is minor, and can be easily reversed by anyone wishing to use their web space moving forward.  

Directions for how to re-enable your web directory, as well as general information regarding using userpages, can be found at https://wiki.umbc.edu/pages/viewpage.action?pageId=31195980.  If you have questions or concerns please contact the Technology Support Center (x53838) and they will be happy to assist you.