Simple Configurable Policy Presentation

Pretty much every site or service on the web has some form of policy document. As it stands, some companies seek legal counsel on what specific language is needed in their policy documents. Others simply find some document for free or cheap on the web and hope it’s good enough. It would be nice if developers had the option of using preset standard boilerplate legal documents. It would be even better if said standard documents could be configured to include or exclude specific clauses. This has “gem” written all over it. Here are some of my thoughts on how that might be best approached.

Note: this is intended for Rails developers, but the gem could be used for Rack and/or Sinatra, and the same high level idea conveys out beyond Rubyland.

RESTful Paths

GET /policy/security
GET /policy/privacy
GET /policy/terms_of_service

Pre-baked Routes

namespace 'policy' do
match 'privacy' => 'policy#privacy', :as => 'privacy_policy', :via => :get
match 'security' => 'policy#security', :as => 'security_policy', :via => :get
match 'terms_of_service' => 'policy#terms_of_service', :as => 'terms_of_service_policy', :via => :get
end

Configuration via Initializer

Specific details of each view (privacy, security, and terms of service) are provided in an initializer. If your service collects personal information from your users, you can include a parameter in the initializer for privacy policy to include a clause in the privacy view claiming your organization will not share that information for profit. If your service provides secure access, you can include a parameter in the initializer for the security policy to include a clause in the security view ensuring the integrity of your users’ data.

Policy.configure :privacy do |policy|
policy.personal_info { true }
end

Policy.configure :security do |policy|
policy.ssl { true }
end

Dynamic Views

Views will include static content in partials. Each partial will represent a clause of the contract or policy document. By using partials, the developer is free to add custom partials to suit situations where default standard clauses are inadequate for their specific needs.

To Be Continued

I don’t see anyone else working in this space, so I will take the initiative to build a first draft of this. I am not a lawyer, so I expect to be relying on my tech-friendly lawyer friends to help me out.

Advertisements

Maximum Wage – A Thought Experiment

I had a crazy idea this morning. With all the talk about deficit spending and growing national debt, I thought maybe we should simply introduce an upper bound on the annual income any individual is allowed to be paid. Instead of a law forbidding any employer from paying above a certain amount, I think it makes more sense to say employers can pay anything they want to their employees, but every dollar above a threshold is taxed at 100%. Here’s a thought experiment.

According to Mother Jones, the top 0.01% of household income is about $27.3M. If there are roughly 140M tax payers, that means there are about 14k people earning over $25M/yr. If all of those people paid 100% tax on every dollar above $5M, that works out to $280B annually. That’s a staggering number.

Let’s compare that to the amount of tax revenue we would gain by eliminating the cap on income that is taxed for social security. For 2011, the cap is $106,800, which is less than the average income for the top 1-10%. If we eliminate the cap, we would collect an additional $39B from the top 0.01% alone, $157B from the top 1%, and $210B from the top 10%. That’s $406B in total.

Combining both figures, it stands to reason we would have an additional $686B in the annual budget with two very simple changes to the tax code.

Sure, folks are going to complain that they’re being treated unfairly and that such a policy would stifle growth by eliminating the natural incentive to acquire more wealth. The way I see it, those people are greedy, selfish assholes. No one person could hope to spend $425k/mo on living expenses. Instead, they buy solid gold toilets, million-dollar cars to gather dust in a garage, and myriad other frivolous things. Meanwhile, 90% of the population is struggling to pay the mortgage on their modest house, feed their families, and live sustainably. I know this is America, land of the fat and greedy, but at some point, even the super rich must feel bad about wasting money on luxury while others starve to death.

Saying No to Noob Users

When you’re first starting out, it’s so easy to get caught up in the “OMG must attract users!!!1!!” mentality. In that state, we are likely to compromise nearly everything about our business model out of desperation for attracting the first round of early adopters. There is a phase of the business lifecycle after the product is stable enough to start marketing and before any actual users have signed up.

Note that in this context i mean users who are not related to you, by birth or even loose association. This means users who have found your product because of a marketing campaign. These users are your audience, the audience you care about.

In this phase, you are especially vulnerable to your own insecurity, more than any other point in the life of your business. This contributes to your compromising attitude that much more, as you lose all confidence in your work at the first sign of anything that isn’t glowing praise. You immediately begin accommodating the interests of those you consider your “core audience” before you even have a clue who that audience really is. If you find yourself in this situation, you may find it beneficial to take a step back and assess who your audience really is.

If you don’t have a firm understanding of your audience, you will fail. You will be unable to maintain a relationship with your user community. You will find yourself in a constant state of overcommitment because you’ve promised different versions of the world to everyone. You will spend all your time trying to find ways of integrating all the fickle desires of your undoubtedly diverse user community, and you will be unable to please any of them in the process.

The key to navigating the sea of user opinion is to acknowledge that you do not want to cater to a nation of noobs. You might be saying, “wait, but i don’t want to exclude people who are not experienced… that’s my whole audience!” If you really believe this is true and your product is not a “how to use the Internet in a browser” tutoring service, please stop reading this for a moment, take a nice deep breath, and say to yourself “i am safe.”

Noobs are not the kind of user you want. You want a user who has a basic understanding of the rules of the browser experience. You don’t want your support community inundated by requests like “i clicked on something and another window opened and i cant get back to where i was. Help!!” It’s ok to expect your users to know that clicking the button marked “back” will take them to the last page they saw. By setting a minimum competency level, you can simplify your support requirements. More importantly, when you’re not spending all your energy teaching your users the basics, you can focus on the things that will improve your usability, like simple, consistent navigation.

At the end of the day, it’s far better to take a tip from language education and emphasize immersion learning. Aim a few steps above the lowest common denominator, and encourage your novice users to explore and learn on their own. Challenging them to take initiative to teach themselves will help both them and you in the long run. Your support staff will thank you.