Salesforce.com Autocomplete may hint at future customization angle
As often happens, I was contemplating a blog post on a topic only to see that Scott had already written it.
In this case it’s the new Salesforce.com Autocomplete Lookups code. The functionality is cool–it turns the standard lookup popups into type-ahead lookups. But more interesting is the way it is implemented.
Salesforce.com could have released this with Winter ‘07. They could have added a configuration setting in the Admin side of the app that would allow you to turn Autocomplete on or off in your database. That’s how they have release changes to the UI–look at related list hover menus, for example.
But they took a different tack here, and exploited a hack that has been available for awhile, but became more useful in Winter ‘07. One the home page of your Salesforce.com instance, you can put arbitrary text, and the Salesforce Heretic showed how you could put code blocks in here and make things happen in Salesforce.com.
In Winter ‘07, they made it so you could have that code execute on every page in Salesforce.com, not just the home page. So when they wanted to release the Autocomplete feature, they wrote a big code block using the dojo AJAX toiolkit and made it easy for you to drop it into the special place where it will execute on every page.
It’s an interesting angle, but not a really sustainable one. There’s only one place to drop this kind of code, so if you were trying to do auto complete and some other stuff, it would all have to coexist. But it begs for a more formal way to do this kind of “greasemonkeying” to the Salesforce.com UI. Maybe the release of Autocomplete is an indicator that they’re heading this way.
February 1st, 2007 at 3:13 pm
We’ve made quite good use of this type of hack for a while. At points in the past year or two, salesforce has threatened to “disable” the ability to do this. They know customers are doing this and will continue to do it, so I’d really like to see them provide an approved mechanism for doing so.
February 1st, 2007 at 3:27 pm
Cool. I thought it was kind of surprising to see a product built this way. Maybe the next release will let you create S-controls that live in the sidebar and get run on each page load. You can kind of do that in Winter 07 on object detail pages, but the s-controls load in i-frames which seems like it would make them very complex to write. Maybe we’ll see a new kind of home page component that calls an S-control in the current window. That seems like the most rational way to do it. There would be lots of power there I think.
February 1st, 2007 at 6:19 pm
“Maybe the next release will let you create S-controls that live in the sidebar and get run on each page load.”
That’s exactly what I was hoping “inline s-controls” would be, and they are — in a way. For many use cases, these s-controls need to load on both the detail and edit screens. Unfortunately, inline s-controls only load for the detail view. Argh. We’ll continue the hacks for the foreseeable future.
February 20th, 2007 at 11:23 am
I’ve proposed just such an idea : http://ideas.salesforce.com/article/show/61105/An_SControl_On_Every_Page and it’s getting good traction. get behind it
“If we could enable admins to mark a (javascript) s-control for inclusion with each page of the app, we could enable the development of seriously cool user interfaces. Imagine the power of the Ajax toolkit available on each page - it would make it possible for developers to create things like :
* Inline field editing
* Mass update objects from view
* Auto complete in picklist fields
These customizations should also be shareable on the AppExchange. It would also be great if each field/ label/ tab was marked with it’s id and had it’s object type as it’s classname so that it becomes easier to introspect the page.”
February 20th, 2007 at 12:10 pm
Cool. I’ll up it as well.