It might be your data, but it’s not your API

Normally the commentary is good over on Hacker News. However, a post I read today concerning Google changing it’s terms for API use caused a bunch of concerned posters to chime in with remarks about how it’s their data, and if they want to give that data to Facebook, Google shouldn’t stop them.

They make the assumption that Google is stopping them. This is simply not the case. You are free to share your Google data with your account on Facebook. You’re even allowed to share your Facebook data with any other social network. Neither Facebook or Google prevent this (that I know of). However, you can’t do this with their API without their permission.

Their is an expectation from hackers that data is only free if it can be easily accessed. However, the assumption here is that easy access should be provided by the company hosting the data via an API (Application Programmers Interface, a set of rules programmers can rely on to perform actions and retrieve data). Essentially, the thought is that by Google changing their terms of API use to prevent Facebook from using Google’s API to extract data from Google about a user (with that user’s permission, of course) is like locking the data to Google. This is simply not true.

The API is governed by Google, not the user. The user is free to do what he will with the data, but a business shouldn’t be required to provide tools for others to grab that data if they don’t want.

Users would do well to remember this. This is why efforts encouraging business to be more formal about opening up is important (and why measure like the GPL exist). What Google is saying is that if you want to use our API to retrieve customer data, you need to allow customers to send their data back to us if they want using your API.

If you want to use the tools we created, you have to pony up and offer tools to do the same.

As a user of these services, it’s important you realize the differences and the reasons. It’s your data, and you can choose how to use it, but it’s the companies API, and they have the same right to use it how they see fit.

Preliminary work went into getting DuctDo started. For faster development, I always find it easier to get a bare bones website up and running so that I know what my minimum feature set needs to be. Beta DuctDo is up with a template from OpenSourceTemplates letting me focus on the content and not the design side. From here, I will bash out simple things.

Sign up – I need to let users sign up with just an email address.

Log in – Needs to be fast and easy. Email verification is critical, so I’ll ask for the password after they’ve verified.

Goals – I need goal creation to be fast and easy. After their first log in, they are asked to create a daily task or goal they want to achieve.

Timezone – I need to grab their timezone and setup intelligent defaults. An email sent out at around 6-7 AM in the morning, and a 6-8PM end-of-day email seeking feedback.

Email Reply – Allow for the user to reply to the email response with a written commentary. Maybe a simple link based system where they are taken to a page where they can fill in their response as well.

Published results – Each user should have an easy to view log of the results, published.

Calendar – To show each day they succeeded in doing what they set out to do.

That’s the bare minimum, I think. Allowing for Facebook and Twitter connection is important, but no need for an immediate setup.

Installing and setting up Doctrine ORM alongside Zend Framework

Picking up from my previous article on setting up Zend Framework, let’s start with at the beginning and go grab the latest Doctrine files.

[server]$ cd ~
[server]$ cd src/
[server]$ wget
[server]$ tar xfz Doctrine-1.2.3.tgz
[server]$ mv Doctrine-1.2.3 ../lib/
[server]$ cd ../lib/
[server]$ ln -s Doctrine-1.2.3/ Doctrine
[server]$ cd ../ZENDPROJECT/library/
[server]$ ln -s ../../lib/Doctrine/Doctrine
[server]$ ln -s ../../lib/Doctrine/Doctrine.php

Pretty simple and straightforward, and mostly setting things so Doctrine will sit alongside Zend.  Remember to replace ZENDPROJECT above with the name of your Zend Project directory.

After this, you want to open your application.ini file for Zend, and add this line:

autoloaderNamespaces[] = "Doctrine"

You also want to generate your DSN for your database connection now as well.  So, add this to the next line:

dsn = "database://"

Save the file.

Now, we need to open up the Bootstrap.php file and create the following function:

protected function _initDoctrine()
    $manager = Doctrine_Manager::getInstance();
    $dsn = $this->getOption('dsn');
    $conn = $manager->connection($dsn, 'doctrine');
    return $conn;

This is the bare minimum you’ll need.  You can actually get by with less, but we are grabbing the DSN from the application.ini we set before.  Matthew has a more complete blog post on the topic, and shares his entire _initDoctrine method with you if you want to initialize your Doctrine instance with additional options set.

From here, you can go ahead and generate your models in application/models and extend them from Doctrine_Record like normal.

Installing and setting up Zend Framework on a Virtual Host

0. Full documentation here:

1. Log onto your account. You’ll most like be in your home directory. You should know which directory is your public directory (Web Root). Usually this is something like ‘www‘, ‘public_html‘, or ‘html‘, or maybe even ‘‘. Regardless, you don’t need to be there yet. In the follow examples, anytime you see the directory ‘www‘, assume it’s the Web Root and replace it with whatever your Web Root is.

Also, in the below examples, I’ll use ‘/path/to’. For me, this is ‘/home/jason‘ For you, it might be ‘/home/username‘, or ‘/home/‘. Whatever it is, it’s whatever comes before the rest of the paths. I’ll use ‘/path/to‘ below, just keep in mind, this is different for each person.

If your not sure what this is, when you first log in via SSH, run this command

[server]$ pwd

It will print out the directory your currently in. This is most likely the directory path you’ll want to use for ‘/path/to‘.

[server]$ mkdir src
[server]$ mkdir lib
[server]$ cd src

2. Download and ‘install’ the source

[server]$ wget
[server]$ tar xfz ZendFramework-1.10.8.tar.gz
[server]$ mv ZendFramework-1.10.8 ../lib
[server]$ cd ../lib
[server]$ ln -s ZendFramework-1.10.8/ Zend
[server]$ alias zf=/path/to/lib/Zend/bin/

You can also place the zf alias in your .bash_profile in your home directory by doing the following

[server]$ cd ~
[server]$ vi .bash_profile

You can also use nano, or any other editor you are familiar with, and add this line

alias zf=/path/to/lib/Zend/bin/

After all this is done, you’ve essentially installed Zend Framework on your virtual host. However, now you need to set it up for your site.

3. Creating your project

[server]$ cd ~
[server]$ zf create project PROJECTNAME

If you have an existing Web Root, you’ll want to move this or remove it, or change it. Basically, at this point, we want the web root pointing to the correct directory in the Zend Project we just created.

If my Web Root was a directory named ‘www’, I’d do this:

[server]$ mv www www_old

Keep in mind by doing this, I can no longer access my website hosted in that directory. We’ll set this up now.

[server]$ ln -s PROJECTNAME/public/ www

In this case, ‘www’ should be the name of your Web Root.

Now we need to need to make sure the site can find the Zend Framework. Remember, it’s in the lib directory.

[server]$ ln -s /path/to/lib/Zend/library/Zend .

At this point, you should be able to go to your website and check out the default web page. Congrats!

Also, log out, and then log back in. If you entered the alias for your .bash_profile, you should be able to run this:

[server]$ zf show version
Zend Framework Version: 1.10.8

Now you can use the zf script helper functions, and proceed with a working Zend Framework setup.

[server]$ zf help

This will also work.

Crazy predictions for the next 5 years

Here are my crazy predications regarding the future of computing, at least as far as operating systems go.  At the moment, there exists three dominant operating systems out there: Windows, Mac OSX, and Linux.  You could argue that OSX is a BSD, and say that Linux is just the kernel.  You’d have a point, but it misses mine.  From a desktop perspective, you’re choices are either Microsoft, Apple, or Open Source.  The problem with this, they aren’t the only players here.  In the world of computing, Microsoft and Apple are really only rivaled by one other company: Google.  Despite Google’s recent problems with Buzz, as well as past issues, they are still in many ways a good company.  They are also a smart company.  They also have lots of money.

Google will build a Linux OS, and make it user friendly.  I want to say they will buy Canonical, and turn Ubuntu into their OS, called Google One.  Wait? What?  They have their own OS…

For phones.

What about Chrome OS?

No.  Google isn’t dumb.  The operating system isn’t going away.  They know this.  Google realizes the power of controlling the environment.  They made Chrome for a reason.  They want people to use Chrome so Google can do all sorts of crazy things with the web.  Oh, it’s great for the web.  What they are doing is being a good neighbor.  But they are also doing it because it allows them to have the control they need.

Look, it’s really simple.  Apple has demonstrated what happens when you control everything.  You can make products people want.  Google realizes this.  So does Microsoft.  The thing is, of the three, Google is the only one who doesn’t control their environment.  Google is at the behest of Apple and Microsoft.  Google took the first steps with Chrome.  Android is another way for them to control a market.  But all of this ignores the one market that Google really needs: the operating system.  The interface to the web.  The interface to your applications.

Suddenly, instead of a Windows or OSX world, you’ll have Google thrown in, and that will be on top of Linux.  Why Linux? Because support for Linux is insane when compared to the other options out there.  Ubuntu has proven that with dedication, you can create a distribution that people will flock to for desktop use.  With Valve’s delivery of Steam and Source to Mac, a Linux client isn’t far behind.  With Google’s backing, Linux would finally become ready for the desktop.

In 5 years, there will be three desktop operating systems to consider: Windows, Apple’s new OS (whatever that is), and Google One.  And you know what?  In that time, developing applications across all three platforms will get easier, especially with the advent of HTML5 and next generation browsers.

Yes, it’s coming.

Bold predictions.  Let’s wait and see.  The benefit is if I’m right, it’ll be awesome.  If I’m wrong, no one will know.  Mostly because so few read this blog.

3, good, white noise sites

More and more often, I’m finding ‘white noise’ sites online.  The idea is simple.  Each site provides you with background noise, or white noise, that will play in the background.  For many people, white noise is comforting background music for both better sleep or concentration during the workday.  Because I love this type of service, I decided to share the list of white noise sites I use.  I find that these are the easiest to use, as well as providing the best features.  I can get to these sites and get white noise quickly and easily.

SimplyNoise is the first one on the list.  It was also the first one I really became aware of.  It offers a number of simple options, allowing you to change the type of noise, as well as the volume.  It is, as the name suggest, simply noise.

The next site is interesting.  As the name suggests, RainyMood is all about rain.  I know I always enjoy the nice calming effect of rain water and the subtle sounds of hearing it fall, and this site does it well.  No options, but a long 30-minute loop.  And the interface is easy; a big button for either pausing or playing.

White Noise 24/7

This site allows you to download most of their sounds.  And they have a large number of them.  Dishwashers, showers, flowing rivers, ocean waves, and hard rain just to name a few.  The site says it has over 21 hours of white noise.  That’s a lot of sound.

Reddit, HN, Digg reducing writer recognition

I’d like to posit a theory: that social news sites benefit more than the sources they link to. Submit a quality article to Reddit, or HN, or Digg, and these sites, not yours, will most likely gain the most benefit of your content. Your site will see an increase in visitors, but it will not see a sustained growth. It will take a lot of work to differentiate your success from the social news site. The reason for this is simple: users equate finding your content with the social news site. The news site gains the reputation for being the source of the content.

This can be seen with Google. Google has gained a reputation, not for creating it’s own content, but for pointing its users toward content. The users credit Google with getting the content, and so Google gains that mind share. This is why Google News is so threatening. Google News merely links to the sources. However, Google News gets the credit, and therefore the readers. Suddenly, people aren’t concerned with branding. They trust in Google News, or Reddit, or HN. If these sources link to the result, the result is good. If they don’t link to the result, then it’s not worth the users time.

Branding is important. The source of content is important. This is something that is known. News Papers for decades worked hard to preserve their branding. The news paper itself was the brand, pointing toward the writers individual articles. Readers would look to the news papers to decide what was important and critical. Front page news is headline news, important, something you need to read. Just like front page news on Reddit is what people have deemed to be most important. Google News is doing what newspapers have done before. Taking the news, filtering it, and presenting what it deems is important.

The danger here is credibility. A source like Digg is controlled by democracy, and must fight against spam. Newspapers had problems with publishers and other problems that they had to contend with. The problems were different, but the results were the same. What ends up on the front page directly reflects the on the brand. Rarely with the actual creator of the content. True, people knew the name of journalists. But how many journalists can you name for the Washington Post or the New York Times off the top of your head? Now, how many newspapers can you name? Probably more, and I’m willing to bet the majority of the news consuming world can’t even name one journalist while naming off numerous news sources.

So, these sources of news become credible because of the work of content creators, and anything posted on these sources becomes credible, regardless of the source. Sure, you have your fact checkers, but it’s far too easy to make a statement and get it into the headlines and bank on the brand of the source. If your article reaches the front page of Reddit, the Reddit population makes certain assumptions. Often times the fact checking is left to the comments (or possibly other headlines later on). But still, the original headline has used the Reddit name (or HN, or Digg, etc) for it’s own purpose. But in the end, it’s content the readers will associate with Reddit, not necessarily the author.

So what does this mean for you, dear reader? The danger is information overload. Something like Digg is supposed to feed you your news. You associate Digg with relevance and meaning. But it leads you to more and more information. You visit a dozen sites each day, and rarely will you remember any particular site, but you will remember what you read through Digg. Or Reddit. And you’ll associate that article with your social news site of preference. You’ll associate that article with the brand of your choice, and as a result, provide that source with more credit then it deserves, or provide your brand with more power than it needs.

I should note I use Reddit, HN, Digg, /., and many other sites each day looking for interesting things to read. I used these sites because I associate them with the type of thing I like to read. Because of this, they enforce and validate the way I view the world. Anything not on these sites becomes suspicious and worrisome. I realize this isn’t just the internet. This is how everything is fed to us. I think it’s coming to that realization, that content and information is re-branded by practically everyone, that makes me wonder how it can be fixed. If it can be fixed.

If it should be fixed.

What I know about designing credit card forms

Credit card forms are pretty simple to make when you first think about it. For many online stores, you plug yourself into PayPal and your done. For other people, you plug your shopping cart into your processor, and you accept the defaults. Maybe someone comes along and adds a custom design, rearranging things a bit, but overall, they don’t change much. After all, the checkout process is pretty simple. It’s set in stone. A credit card form is simple. People are used to it, they know what to enter. Credit card forms are simple, common place, and boring.

Checkout my credit card form

The truth is, credit card forms are far from common place, they are far from simple, and while you might consider them boring, a checkout process, and by it’s nature, the credit card entry form, can actually be very, very interesting.  I should know.  I’ve spent the last 8 years working with them, and every step of the way, I’ve attempted to learn more about how to make them as easy as possible.  With that much experience, let me make something clear: the credit card page is the do or die page.  It’s the page where a user will either make a purchase, or fail.  Your job is to get make it as easy as possible to make that transaction.  Every error you present to the user is another chance that user will decide it’s not worth his time and energy to make a purchase at your site.

Too many sites make the credit card form just another form.  They provide basic error checking, but let’s be honest, the credit card form is where everything matters.  Capture that information, and you can make money.  Fail, and you can’t process anything.  It doesn’t matter what you do.  So much effort is put into the shopping cart, in shopping, in the front page, in the privacy settings, in the product pages, in everything else we do.  But at the end of the shopping cart experience, or when the user is about to make a membership purchase, the credit card page is all that stands before them and the final purchase.  You want that person to make that purchase.  It’s the only way you can get paid.

Don’t believe me? How many people get to your purchase page and bail out?  How many get there, get some sort of error, and fail to finish the transaction?  What is your most common error? Do you email the user after failing to submit a credit card?  How long does it take to complete your checkout or purchase process?  How many attempts does a user make before making a successful transaction? How many do they make before not attempting? How many failed transactions do users make if they don’t make any errors?

These are all questions that are important to online retailers.  These all provide vital clues in how people are making purchases online.  However, I don’t think people put too much weight into looking at numbers like this.  After all, what’s so important about how long it takes to complete a purchase?

Time is vital.

Time allows the person to second guess their purchase.  It allows for other things to distract the user from making the purchase.  Take too long, make the process too cumbersome, and the might not make the transaction at all.  Numbers are important here.  Find out how long the average user takes to complete a purchase after they start the checkout process.  From start to completion.  Getting this information lets you know how fast or how slow your form is.  Speeding up the process will increase sales.  Cutting even a minute off the purchase means the user has less time to decide against the purchase.  He makes the purchase, and it’s done, and he’s happy.  No more questions, no more concerns.

What about errors?

Common errors are a problem.  Common errors are a failure on your part to correct mistakes for the user.  Should your users suffer because of a typo?  But what kind of common errors could you fix?

Phone numbers.  Phone numbers are a major problem.  When I was developing my credit card processing system, we were doing telephone authentication long before PayPal and others got on board.  The problem is, on a world wide scale, making sure phone numbers are correct can be difficult.  After all, we had a single call center making all the calls at the time, so the calls were made from the New York area.  Now, for Americans, it was pretty simple to make sure the phone number was correct.  However, most people over in Europe or other parts of the world weren’t entering in phone numbers that could be used to call them from New York.  They were entering local numbers.  I remember spending some long hours reading up on phone numbers and creating a system that would automatically fix their phone numbers, entering in proper country codes, recoding them if necessary, and basically modifying the number they entered to ensure that we could make the call.

Sure, I could have thrown an error and told them they had to enter the phone number correctly.  In some ways I did them.  I had some helpful information providing country codes in a nice little pop-up window.  But since I had the information anyways, I could just automate the fix for them.

Emails were another issue.  user@examplecom is not a valid email address, but is.  It wasn’t uncommon that I would get com without the dot, and fixing that proved to be helpful.

Keep in mind that each of these errors were, at some point, errors that stopped a user from purchasing.  Often times they weren’t the only error, but they were an error.

A really easy fix was removing the credit card type selection.  This was done early on.  After all, I could easily figure out the type of card by the credit card number entered.  Selecting the card was useless for me.  It was an extra step I forced upon the user.  Even worse was when the user would enter in one credit card number and not change the credit card type.

Asking for the credit card name was another problem.  It might seem simple that you ask for the name on the credit card, but you’d be surprised at the number of places that require a first and last name.  Even worse, some gateways would request the first name and last name rather than as a whole name, while others wanted the full name on the card. The quick and easy solution is to ask for the first name and last name, and combine them as needed.  The problem here is the user needs to enter in his middle name, or middle initial.  Even worse is that with two fields, the person will probably have to click his mouse into the next field, taking even more time to fill in the form.  Sure, tabbing works, but users usually don’t tab through a form.  But why even force them to tab?

One field: Name.  If you need to split the first and last name, simply split it along the space.  If they enter in a middle initial or a middle name, you can detect that and store it as needed.  Essentially, you are given more information to work with, and can still provide all the needed information.

The CVV2 is another major problem, though thankfully people are used to it by now.  However, it’s still something people need to enter.  I found that letting people know about this number and where to find it was best done based on the type of credit card they were entering as well as providing multiple locations to show where the number was.

First, I’d have a little image, about the size of the text box itself, next to the input box, that showed a small credit card with a little circle where the number was.  I also had a nice little “What is this?” link next to that.  The user could click, and a small pop-up would appear beside the input area.  The image was different depending on the type of card, and we tired our best to pin-point where the number could be found.  Some cards have 4 digits followed by 3 digits.  The 3 digits are in fact the CVV2 or security code, but the previous 4 are part of the credit card number.  Usually the last 4 numbers.  Sometimes a user would try to enter those 4 numbers along with the other 3.  We had set our CVV2 space to a maximum length, but eventually noticed the problem.  We allowed the user to enter in more numbers, and just made sure to remove the numbers we didn’t need.  Again, why bother the user with providing us with 100% accurate information.  If they give use more than we need, we can always strip out the excess.

Email first

While not directly related to the credit card, the email address is something every online e-commerce system is going to collect.  Without a doubt, it’s the way to communicate.  What I’m about to suggest might be something that some people might consider to be underhanded, but used correctly, it can provide value to your customers, increase sales, and help solve problems you might know ever existed.

I’m talking about moving the email address up to top of the form.  Make it the first piece of information that is requested.  As soon as the user finishes entering his email address and moves on, a quick ajax call to the back-end stores the email address next to the purchase information.  This is where it can get shady.  You don’t want to spam the user, but you do want to assist the user in getting what they want.  If the user fails his purchase for whatever reason however, you know have a means by which to follow up with that user.  Even if the purchase isn’t successful because the form is never submitted successfully.  Let’s say even if the user starts to fill out a form, and then stops half-way through for whatever reason, you now have a means to follow up.

One thing you can do is provide the user with an incentive to complete the purchase.  Emailing the customer  with a different price let us capture even more purchases than previously.  Knocking off 20-30% of the price helped encourage the user to come back and complete the purchase.  We were also able to use the time the user was going to make the transaction as an indication of when the user was available.  I felt it was safe to assume that if the user was browsing at 3 PM and was going to make a purchase, emailing him the next day around the same time asking if everything was okay wasn’t a bad idea.

What do you really need

Credit card forms are simply complex beasts.  They are where you either make money or you don’t.  While it might not appear that any of these suggestion alone will seriously increase your profits, together, and over time, they will help.  Of course, this requires you to keep track.  Every transaction, every error, every piece of data.  Knowing what people do, how people use it, what information they get wrong, what information they are entering, all of this is vital.  You might be surprised at how many little improvements you can make that, in the long run, help increase how much money you make.

To figure out what you need to do, you really need to track everything.  Once you fix the problems, you need to track the places where the transaction would have failed if you hadn’t made the changes you did.  This is good because it not only provides you with a direct view into what you are doing right, but it also makes you feel good.

With all that said, this is just the tip of the ice berg when it comes to designing and developing for e-commerce systems.  But I really think these are the fundamentals.  If you aren’t tracking, if you aren’t correcting, if you aren’t taking the basic steps now, you can’t move forward.

What we can learn about privacy from Google’s Buzz fiasco

If your not a regular internet user, you might not be aware that Google’s Buzz has sparked a lot of criticism regarding it’s privacy policies.  Basically, the problems weren’t as bad as everyone made it seem, and privacy settings were in place to prevent everything that came up.  In many cases, the claims were simply not true, or the issues weren’t exactly as described.  In the case of one blogger, they were partly right and Google did fix a display bug, but even in that case, the private information wasn’t disclosed.

But this post isn’t about any of that.  Enough has been written about this, and frankly, everything I’ve read has amounted to nothing more than repeating was has already been said, and we haven’t moved toward learning anything from this incident.  That is what this post is about: learning.

Privacy: What is it good for?

I use my private Gmail account to email my boyfriend and my mother.

There’s a BIG drop-off between them and my other “most frequent” contacts.

You know who my third most frequent contact is?

My abusive ex-husband.

Which is why it’s SO EXCITING, Google, that you AUTOMATICALLY allowed all my most frequent contacts access to my Reader, including all the comments I’ve made on Reader items, usually shared with my boyfriend, who I had NO REASON to hide my current location or workplace from, and never did.

First, let’s make it clear that Google didn’t allow people access to her reader.  This was merely a display error that showed that certain people had access, but really didn’t.  But, this post is probably the greatest argument against “If you aren’t doing anything illegal, why do you need privacy?”  It’s a real life answer that has real life implications, and shows why it’s important to consider what we can learn from this.

Privacy is also important at a business level.  My actions, my privacy, the data I create, are mine, and I have a certain right to them.  Sure, I use Google, and I accept that they track my movement online.  The price I require Google pay is a good service.  It knows me, so it can innovate and create new features in search and other areas that work from that history.  If Google ceases to pay that price, I can always stop providing my goods, that is, stop giving them more information to use.  There are numerous ways to do this, and it devalues Google a little if I remove information from their system.  After all, without that information, they can’t provide services to other people.  Indeed, that’s show search engines work.  They provide a service as a payment for using your information.  When their service isn’t valued, you remove your information from their system, devaluing their service.

But this presents why privacy is important even beyond just a right.  My actions, my content, the data I create, are mine.  An email I write, a blog post I create is mine, and I have the right in many ways to control the use of the product.  Google doesn’t have to provide it’s search service to mine.  It doesn’t have to direct traffic to my post.  I would lose that payment, but as the content creator, that is in many ways my choice more than Google’s.

The simple fact is, for many people, providing Google with data allows Google to do a better job at providing their services, and we value that service at a certain level.  A level where we have no issue with sharing our data to a certain extent.

That’s the business side of privacy.  It’s our data, and we have a right to control it.

Who controls privacy

Computers suck at intent. Inferring privacy preferences for new software, based on prior actions in old software, is a recipe for failure, and a PR nightmare.  People assume computers are great at intent. We publish things to much wider contexts than we intend, and don’t notice or care until new products and features make incorrect inferences based on that. – On Privacy (or: what Buzz failed to learn from Newsfeed)

This is probably one of my favorite quotes that came out of this incident.  More precisely, “Computers suck at intent.”  The other side of the coin for me is this: “People assume computers are great at intent.”  A great example of the later is the Facebook Login fiasco.  People make the assumption that the computer works the way the think it should work.  They think computers understand their intent.  This is obviously not true, to a point.  Google does go a long way toward trying to understand the intent of the user.  All that data they collect is directly related toward enhancing aspects of their business: search and advertising.  If they can better understand users and use that data to deliver that user relevant search data, they can also use that data to enhance the ads they show.  And the ads they show are in many ways geared toward helping us.  Their is a fine balance between an ad that adds value and an ad that is just plain annoying.  However, a search engine is nothing more than a giant advertising engine.  The difference between search results and ads is merely that ads are paid for with money.  Search results are paid for in different ways, as described above.  It’s another case of give and take.  You give Google the ability to search your site, categorize it, and use it to better provide users with what they are looking for, and for that you are rewarded with more visitors from Google.  But we’ve already discussed this.

The Facebook Login fiasco demonstrates the value that Google provides, and the strong case that people really do thing computers understand intent.  But Google Buzz also shows us that computers can’t understand intent.  The second sentence of that quote explains succinctly: “Inferring privacy preferences for new software, based on prior actions in old software, is a recipe for failure.”  Now, I don’t think this directly relates to Buzz (I think Buzz was seen by Google more as a new feature of Gmail rather than a new product like Docs or Reader), but it still relates in some ways.  But it’s also essential to understand this because it all relates to who controls privacy settings.

Now, it’s easy to say you should be the one to control your privacy settings.  But what Buzz taught us is that most people don’t.  They assume the computer is controlling it for them, and that the computer understands the intent of the user.  Computers don’t.  This is why Buzz relied on existing privacy settings.  Settings people were not aware of.

On a slight side note, I’ve been using Profiles for a while now, and I had made myself aware of the settings.  I made the assumption that most other people would utilize the tools if they weren’t happy with the defaults, and anything concerned at all about privacy would take the time to make themselves aware.  On that last part, I was wrong.

So, who controlled privacy? I could argue that the individual should have been more diligent about their privacy and looked into this sooner.  The fact is, a lot of people were very much unaware of the tools available and were scrambling at the last minute.  Settings that were obvious to many of us who took the time when the tools were provided were shocked that settings that had been in the same place for years were suddenly proclaimed to be hidden.  It’s as if suddenly the populace of self-proclaimed privacy-aware individuals suddenly realized that they had to make privacy changes, rushed to the website, and scanned quickly for the big flashing “Privacy Settings” link.  When they couldn’t find it within the first few seconds, they proclaimed loudly that Google was hiding these things from them.  Hiding settings that have been available for a long time.

But I digress.

Anyways, the ability to control all of this was in the users’ hands, and I could argue they elected to not use the tools provided.

But, I could also argue the opposite side of things.  Google clearly didn’t make important parts of this new feature clear enough.  Lots of people had concerns, and suddenly, without warning, a cry of alarm sounded.  Doing things without explicit permission is dangerous.  Sure, Google might be relying on privacy settings that the user agreed to by using the service, but most likely, these were the default settings that the user never really looked at.  Surely Google must realize that a default setting is really Google making the choice and not the user?  If someone never viewed their privacy settings, if someone never said “Yes, I want to use these privacy settings” explicitly, is this really a choice?

Yes, it’s a choice because the user accepted the default settings.

No, it’s not because the user never explicitly agreed to settings they weren’t explicitly aware of.

Google was right in using the default settings.  What other settings could it use? The users used the service, accepted the settings by default.  Should Google not use these settings? Should they make up new settings?

Google was wrong because the default settings were given additional meaning.  Not new meaning, but the average user couldn’t apply the new features, the new explanations, and keep in mind the new issues that might arise.

Let me explain that last part there.  Google Profiles could be made private.  Google Buzz followers would be displayed on your profile.  Contacts could be automatically followed to your Buzz.  In the context of the Buzz situation, is it easy to follow that your contacts might be display on your profile for the world to see?  No, not really.  Is anything inherently wrong? No, not really.  Google is merely display what amounts to what Twitter and numerous other services already do.  They are following the status-quo.  The implications aren’t immediately apparent.

At the same time, you have all these informants and what not who emailed journalists from emails that could be traced back to themselves.  The journalists apparently stored these people as contacts in such a way that made them traceable.  These people who wished to remain anonymous were no longer in control of their privacy.  They allowed their privacy to leave their control.  This isn’t even a Google thing.  It’s a control thing.  The more private information you give away, or the more often you give it, the less chance it will remain private.  And the less control you have over it.  This is important, because the problem here has to do with privacy policies we set for ourselves.  The informant allows the email they use to be traced back to them.  The journalist allows information to be traced back to the informant by storing it.  The informant allows his private information into the hands of someone who’s privacy concerns are shared, but not enforced.

Concerning ourselves with our privacy is a right, but like all rights, we have to exercise this right.

What to do with all of this

So far I’ve typed a lot, but I don’t think I’ve said much.  Here is where I hope I will make up for the length of this post.

Privacy settings should be explicitly defined, accepted, even if just accepted as defaults.

The problem with this approach is the “Next, Next, Next” syndrome.  People click right past it.  Already privacy policies are displayed, but rarely read.  Privacy settings displayed will just be seen as another hoop to get through.  If privacy settings change, logging into the service will be a nightmare.  After all, I don’t want to concern myself with saying “Yes, I Accept” to every new change.  It also doesn’t solve the problem of finding the privacy settings once they are set.  After all, using the service might make you realize you want to set the privacy settings differently.  But do we really want an obtuse UI that asks our permission to do everything little thing?

After all, most people are willing to accept some lack of privacy control for ease of use.

On signing up for a new service, or agreeing to a new feature, it would be nice to see these policies and allow me to review them, but I also feel it’s somewhat counter-intuitive to ask the same questions over and over again.  But at the outset, the initial launch of a new piece of software, a review of policies and how they apply to the new feature should be made easy to get to.  Don’t clutter the UI, but allow me to review the policies that are needed.

Design an interface that is removed from the website

This is the big idea here.  We already do something like this for SSL certificates.  Browsers display this information to the user in way that they hope is easy to use.  Phishing sites and other dangerous sites are also monitored, and users are protected from those sites by browser makers.  It’s a real problem.  Privacy concerns are also something that is a major concern, but privacy on a site-by-site basis.  There is no standard, but this shouldn’t be that hard to correct.  After all, RSS feeds are already supported by browsers.  Why not take this a step further and support Privacy URLs.  This would be the location the site proclaims as their “Privacy Center.”

I propose two types of links:

<link rel="privacy_policy" href="">
<link rel="privacy_settings" href="">

Using these like you would RSS feeds, you allow the browser makers to create buttons, widgets, or whatever to allow the user browser based control to go immediately to the privacy policy and settings for a website. Just like an SSL certificate, it gives the users a way to avoid dealing with a sites design. It also allows the software developer the knowledge that even if user misses the information on the site, they’ve given the user a default way to access privacy settings.

Essentially, this is a common, default way to access something that is rather important. This can be further used by allowing sites to change privacy settings by simply changing the URL they use in the header, and this would notify the browser that the site itself has changed the policy, and can then alert users. This alleviates the developers from coming up with numerous ways to make sure their settings are noticed. They should still allow access via the website by normal means, but it also provides them with additional tools. In a way, it would also make users more aware of privacy settings they might not have otherwise taken the time to explore.

Going this route, I believe we solve a number of the problems.

First, we have a common way of notifying users, alongside other traditional ways. A big problem with Buzz was not finding the settings. The location, while not necessarily hidden, wasn’t obvious. A simple browser button or UI feature would allow us to worry less about finding this information, and deal instead with acting on the information.

Secondly, having these settings in place allow easily review of these settings at any time. We know that we are at the right place, the place that contains all the privacy settings, or the privacy setting center of the site. This is the right location. We aren’t guessing if we are in the correct place. This was another issue with the Buzz roll out.

Finally, this allows companies to update privacy policies and privacy settings in a much more efficient and simple manner. Updated and new settings can be alerted to the user, and the user has an easy place to review these new settings, and it’s within an appropriate context.

Combined with the first step, this would essentially make privacy as important as other features people find important in browsers. Browsers are, after all, the vehicle by which we surf the internet, and this idea, I think, is sort of like your seat belt, something you put in place before an accident happens.