Archive for January, 2006

Using the + Sign in Email Logins

Tuesday, January 24th, 2006

Most applications on the web require that you create a username and password, and many have gone to using an email address as the username. This is nice because it’s easy to remember, but it can be hard if you want to have multiple accounts on one system. To have multiple accounts, you have to come up with multiple email addresses, and they have to be real addresses because there is usually a validation step where they email you something to respond to.

Salesforce.com works this way. Of the 300K+ users on their system, each one has a unique email address. For most of these users, they use their work email and they’re done. I, however, have the problem of needing a login for my organization’s Salesforce.com database, one for my test database, and one on each of my client’s databases. Right now I need 5 accounts in Salesforce.com, which means 5 valid email addresses–a real nightmare.

Good news is that there is a neat trick with email that can get you around this problem. When processing addresses, if a mail system runs into the “+” sign before the “@” sign, it will skip to the “@”, effectively ignoring everything that comes after the “+”.

Example:

Bob@testemail.com looks exactly the same to a mail system as Bob+anything@testmail.com. Email to either of those addresses gets delivered to Bob@testemail.com.

The great thing is that systems like Salesforce.com see those email addresses as different, so Bob can use them as logins that deliver to one real email address, thereby getting past the problem of having to set up multiple “real” email addresses.

Application Features vs. API

Thursday, January 19th, 2006

Interesting article over at Skype Journal talking about the Skype application and how the API stinks. Their main point is that an API can be tacked on to an application, or can be the core on which the application is built. If an application is built with the API at the core, it can become a platform that others can build on top of. If the API is an afterthought, it will not empower the greater community of developers to adopt the platform and extend it beyond what the application developers can do. They posit that Skype hasn’t embraced the API and won’t take off as a platform until they do.

A lot of applications are playing API catch up right now. You almost can hear the CEO saying at staff meetings, “We need an API for web 2.0!” They have a long way to go to catch up with Google, Salesforce.com, and others who have realized that the API is key to putting power into the hands of developers. And by giving outside developers power, they give their application huge competitive advantage.

Interesting API as Platform tidbits:

  • Google released a feed reader application a few months ago. Frankly, it was a pretty lackluster application that lacked a lot of usability and functionality in other tools like Bloglines. But then I heard the real story–Google built the news reading API first, then built the reader app on top of that as a proof of concept. To them, the API is the important product. Wow. That is commitment to the platform, not the application.
  • Fully half of the traffic that hits Salesforce.com’s CRM application does not come to their web app–it accesses the API. Half of their traffic could care less that the web front end even exists.

To the application builders out there: Do you have your API closest to heart? Or are you building your functionality first, and creating the API later? Firefox and Chandler are two examples of open source software projects that focused on API in their early stages. Problem was, neither had any features to show for at least the first year of their existence. That stunk in the short term, but look where Firefox is, and a lot of it’s popularity comes from the Extensions that people build against their API. And what about Chandler. You haven’t heard about this project? In 3 years you will have–I think it’s going to be wildly successful because they are taking the API driven aproach.

API driven services are the future, and it’s one of the big reasons I chose Salesforce.com as our CRM platform. Power to the People!

New way to Handle Households in Salesforce.com

Saturday, January 14th, 2006

The new version of Salesforce.com changed the way you could relate objects to each other. I had an idea that this could be very powerful, but my naive realist brain needed to see it to believe it.

Indeed, this is very powerful. It has allowed me to greatly simplify the method I use to handle Households. I suggested that things might be better earlier, but they are much better than I thought.

I can now create one custom object called Household that can hold the address info for the house, and then I put a lookup field on a Contact that allows you to associate them with a single Household. Once you do that, there is a report recordset called Opportunites with Contact Roles and Household that you can use. It will give you all gifts by individuals, but groupable by Household.

Very nice, simple, not overly complicated. Interface is clean, and easy to explain. Now I just need to create an S-Control that is a form for creating a contact, thier Household, and their spouse all in one. Would anyone be interested in seeing that?

When I have a minute, I’ll be publishing my steps for setting up Households in Salesforce.com in a nice clean PDF.

[Update]: Here’s the promised PDF on how I set up Householding.

Problem with Comments

Friday, January 13th, 2006

I wasn’t getting any notifications of new comments, and I thought it was because there was no one commenting. Turns out, there was a couple week backup in the comment moderation queue. That’s cleared up, and I’ll work on the spam controls so I don’t have to moderate everything. If you feel the urge to comment, please do!

Real World Process Work: Two Cases

Wednesday, January 11th, 2006

I went into my work with clients armed with a plan for helping them outline thier work processes. I’d listen to them tell me about what they do, I’d ask lots of clarifying questions along the way, and capture the process in a flowchart format. I wanted them to tell me how they work–I didn’t want to be leading the process.

With one of my first clients, this plan has worked great. They are an old-school conservation organization that knows exactly what they are doing and how they do it. They actually enjoyed telling me all their processes and identifying areas where they felt limited by technology. They loved the flowcharts and are totally digging the process stuff.

With one of my next clients, this didn’t work. They are a new group that has been doing this work for about a year. They don’t have a lot of process, but have gotten great work done in ad hoc manners. When I let them lead the walk through of the work they are doing, I got lots of pushback. They saw it as an inefficient process, and many of my granularity-seeking questions were met with comments like “I’ve already told you our process for this” or “we’ve only done this once, so we don’t have a process.”

It has become clear to me that process mapping of existing work is easier when people have been doing it for awhile, and are in a place to reflect on what is and is not working. When you ask someone who isn’t in this place about all their processes, they can feel a combination of being overwhelmed by the size of it, and being threatened because they haven’t had the time to think through things. Understandable, as the first few years of any nonprofit are a whirlwind of acitivity with very little time for reflection.

So, I’m trying to ask fewer questions with this new group, to be more respectful of where they are in their lifecycle. Their needs are simpler than the older client, so I should be able to get less granularity and still deliver the CRM they need. We’ll see!

New Salesforce.com version and Households

Tuesday, January 10th, 2006

Householding is something that Salesforce.com hasn’t been good at. If you want to take donations from multiple people, and then thank them with one letter at the end of the year that aggregates all their donations, you had to go through some gyrations. The most comon gymnastic was to co-opt the Account object (usually meant to represent a company) and use it to represent a Household. This allows the report identified above, but has other consequences that have been a deal-breaker for me.

With the new Salesforce.com release, which came out this weekend, another workaround became possible. You can now relate a Household to an Opportunity. This allows you to record a $100 donation with Bob Horton as the donor and also relate it to his Household. Do the same thing with donations from Sue Horton, his wife, and then run the report that shows all Opportunites for a Household and you’ve got it.

To make this easy to use, there probably needs to be some custom code for creating Opportunities and automatically relating them to the right donor and Household. I’ve written part of this, and I’ll augment it to support the Household portion as soon as I can. Then I’ll tackle the non-trivial concept of thanking individuals vs. thanking Households, and the best way to do that.

Thanks to Salesforce.com for giving us more options!

Overcoming friction for the greater good

Tuesday, January 3rd, 2006

One of the things I really like about commiting to writing blog posts about once a week is that it has made me prick my ears up when I have more than one conversation about a topic. If the same thing comes up twice, in different contexts, it makes me realize it might be important.

Twice in the last week I have found myself talking about how the key to creating shared value in a technology system is removing the friction for the individual user to create content that is valuable for the group. The first time this came up was with Netflix, the movie sharing service.

Whenever they list a movie, they show the overall rating that users have given the movie:

Fog of War

When you mouse over the stars, they turn gold and you can click on them to set your rating. When you click to set your rating, it gets put in the database. No page refresh, no change other than the 4.5 red stars turns to 4 gold stars.

Fog of War

When you rate a movie, you don’t get kicked out of your current context. You aren’t abused by a big popup that says “YOU’VE RATED FOG OF WAR 4 STARS!” They’ve made rating nearly frictionless. It’s so easy that before I knew it, I had rated 312 movies. No way I would have gotten past 10 if they hadn’t removed the friction.

Ratings are great for me to remember what movies I like, but they’re even better for others on Netflix. My rating adds to Netflix’s aggregate rating that everyone sees when browsing movies. Even better, my Netflix “friends” can see all my ratings, which they can weigh based on what they know about me, and my taste in movies. They get value from this, not becuase I’m a great movie critic, but becuase it’s some more information in their decision making process.

This same concept–removing hurdles for users to create value for others–came up today in an email conversation with a smart colleague who is building CRM for nonprofits. He’s working through how to build functionality that will allow a history of all communications with a constituent to be centralized in one place. He knows what he’s up against–too much friction and the users won’t do the extra work to get the shared benefit. But if he builds it well, users might not even notice that they’re contributing to the whole.

This kind of design is one of the hardest parts of “social” technology systems, and it’s on the top of my mind this week.