Archive for The Community

A new Facebook Group popped up recently called “Salesforce User Community 3.0“. The group moderator, Pete Fife, asked me to communicate the following note to my readers:

Do you wonder if Salesforce.com listens to their customers and what they want from the user community? Take it from me, they do even if it takes a little squeaking to get their ear. Join me, Pete Fife, to discuss taking the Salesforce.com community beyond disucssion boards and into the new world of social commuinty. I started the customer salesforce user groups back in 2003 and although we have come a long way since then, there is a long way to go to really enable us customers to define our own vision of the Salesforce.com Community. Take advantage of the chance to bring our collective wishes for the user community to the ears of Salesforce.com. They are our captive audience and ready to listen.

Join the Facebook group Salesforce User Community 3.0 to stay up to date and find out when and were we’ll meet at Dreamforce.

The new Force.com Toolkit for Google Data APIs provides a free and open-source set of tools and services that developers can use to take advantage of Google Data APIs from within Force.com.

The end result for developers is a set of classes, written by Salesforce, that allow you to easily communicate with Google services. For example, suppose you want to create an entry in Google Calendar, the following code does it.

That is actually just 2 lines of code (line #2 was broken into 5 lines for easier reading). The reason you can do this in 2 lines is because of the toolkit. The toolkit does the “heavy lifting” for you to communicate with Google.

From a developer standpoint, the best thing about this is that, to do this, there is no dependency on changes to the Salesforce platform. The Google Toolkit was created by the Developer Marketing Team at Salesforce, not the folks building the platform. Apex Code is already part of the platform. The toolkit uses what Apex Code already offers. What you get with the toolkit is a set of pre-written Apex classes that do the heavy lifting for you on talking to Google. Much like the Salesforce Java/PHP/.NET/Ajax/Perl toolkits do the heavy lifting of talking to the SOAP API for you on those programming platforms.

There is no reason that the developer community cannot create similar toolkits. I am sure Salesforce has some more up their sleeve and did the community a service by building some foundational ones for us to use as working/useful examples.

This is open source at work. To make an analogy… one thing I love about PHP is that these types of toolkits are prevalent and have made my life much easier. For example, when I wanted to build Auto vCard, I Googled for PHP classes that created files in the vCard spec. I found many and chose 1. Similarly with the Web to Lead Spam Check I built. I chose Akismet as the spam checking service because I was familiar with it and trusted it and I found a PHP5 toolkit that took care of the hard part of communicating with Akismet from PHP. Same thing with my old Google Maps mashup. There are PHP classes that do the hard part of talking to Google Maps. Having these classes at my disposal gave me the ability to focus on adding the business value of tying functionality into a Salesforce-related use case. If these PHP classes didn’t already exist, I never would have created any those apps.

If you are a developer looking to create something similar to what Salesforce did, I suggest you:

Visit Programmable Web to identify useful services that could be connected to and learn about their APIs

Build your class(es) (Look at the XMLDom class that’s part of the Google toolkit to handle the complicated XML parsing you might need to do)

Publish it open source and let the community react/improve it

Offer up some example code for how the class can be used to help people implement a use case of it.

Become a star

Some services that I think are ripe for developers to concentrate on (that are very applicable to businesses):

Greasemonkey is a Firefox extension that allows you to customize the way webpages look and function. Hundreds of scripts are already available for free. And if you’re the tinkerer sort, you can also write your own.

Someone created a greasemonkey script for Salesforce.com, called the “Salesforce Cold Call Mashup” (for more information). It’s the first of its kind, to my knowledge, and brings up an alternative approach to designing/distributing improvements to the Salesforce.com experience. The ability to utilize a Greasemonkey script is outside of the development tools Salesforce offers and allows you to just overlay new functionality, developed in JavaScript. It is not distributed via the AppExchange and it can be deployed on a user by user basis.

The script just released doesn’t do anything more than you could/should do within your own Salesforce environment. It looks at the Account Name on an Account page and auto-creates links to various search/news sites and puts them in a convenient location on your Account page.

I don’t think this particular script is revolutionary, but it acts as a proof of concept and brings up an interesting way to look at Salesforce development. Pros and cons (imho) of this approach:

PROS:

Easily distributable on a user by user basis

Can be turned on/off very easily by the end-user, putting the end-user in control of their experience

Developed outside the Salesforce framework if that’s your preference

You can place the output anywhere on the page. You are not limited to it being contained in a Page Layout specific location (see the image above for how they did it).

Can apply to any Salesforce.com environment vs. needing to configure a solution within each org. Thus, it could be handy for a consultant-type / Salesforce Engineer that jumps from org to org.

Could tidy up the Salesforce UI in places that need it prior to Salesforce doing this for us. In fact, if a motivated developer started putting out some scripts that really made a difference and gained in popularity, I bet they’d be able to influence future Salesforce.com design in a similar way to a popular idea. For example, people have been using Greasemonkey for several years to add new functionality to apps like gMail, Google Calendar, del.icio.us, Digg and countless others. The good ideas bubble to the top and have been incorporated into these apps.

CONS:

Limited to Firefox. Most companies are not standardized on that.

This approach could cause some renegade development and could be a risk to security and user experience within companies. Admins may not like this type of thing getting too popular as they lose control of the app.

Developed outside the Salesforce framework, so it’s unsupported.

Would not support the JavaScript/AJAX API to access other Salesforce data. Well, I never tried it, but can’t imagine it would. If it does, then Salesforce should plug that hole, since that would theoretically open up the door to attacks since it would only take a single, random user to open up the door into the database.

Needless to say, I won’t be recommending this approach on my client projects. Visual Force pages will definitely be the way to go for true, supported solutions.

However, I’d like to encourage the developer community to work on some scripts that would be useful to the rest of the developer community. Think of handy things that could be added to the Salesforce GUI that a developer would like to have at their fingertips regardless of the org they are in. It could be as simple as removing links, images and other HTML elements that are not useful in Salesforce (e.g. the “Brought to you by…” image on the sidebar of DE Orgs) or as fancy as anything your creative mind can think of.