Social Glass

I recently had a discussion with Sam Lawrence, Chief Marketing Officer at Jive Software, about his take on social computing in 2008.  I’ve written about Jive several times and have been impressed with Clearspace - Jive’s Enterprise 2.0, social productivity application.  Below is a summary some of the things Sam and I discussed. 

Jive - Company Background

Jive Software was founded 7 years ago and, until recently, was entirely self funded.  In 2007 Jive Software received $15 million in funding from Sequoia Capital (although they’ve been profitable from the beginning) - the same firm that financed the likes of Google, Yahoo!, Youtube and Meebo.  Sam’s take on Sequoia was that they weren’t just bankers, they actually add business value. 

At the beginning of last year, Jive had 35 employees.  Today they have over 100 and anticipate continued growth in 2008.  Sam mentioned that going public isn’t a business goal, but that if they do go public it’ll simply be a “means to an end”.

Jive has over 2,000 business customers, 250 of which have purchased Clearspace. 

The Enterprise 2.0 Market

I asked Sam what his reaction was to Jevon’s post about the Enterprise 2.0 Market, where Jevon asked “Is there such thing as an Enterprise 2.0 market? If so, can you sell in to it? If not: are there startups trying to sell to customers who don’t exist?”  Sam’s take on this is that there absolutely is an Enterprise 2.0 market, how else could they be making money with Clearspace if there was no market?  Sam went on to compare the E2.0 market to the CRM market of 10 years ago, where people argued that customer relationship management couldn’t be generalized.   But try making this argument now with companies like Siebel (Oracle) and they’d probably laugh at you.

Sam also pointed out that Google is a huge player when it comes to Enterprise 2.0.  They’ve recently announced that Google Sites - an evolution of JotSpot - will be released in 2008.  “Sites will allow business to set up intranets, project management tracking, customer extranets, and any number of custom sites based on multi-user collaboration”.  Google’s focus on social computing within the enterprise is validating the Enterprise 2.0 market.  Sam thinks that Enterprise 2.0 vendors like Jive Software will benefit greatly from this as they can ride the tidalwave created by Google.  Companies will become more aware of what Enterprise 2.0 is in 2008.

2008

Jive is a firm believer in social productivity.  When it comes down to it, social computing is about getting work done efficiently.  In 2007 Jive’s focus was on building a compelling collaboration suite.  In 2008, they’ll focus more on enhancing social productivity in the following ways:

• Relevant Visibility - who’s working on what and what matters most
• Influence - encouraging productive behavior and resource alignment by allocating resources where they’re needed most
• Management - knowing the truth of what’s happening and focusing the attention of others

Jive also is a firm believer in harnessing the knowledge of the customer community with products like Clearspace X and will be focusing a lot of attention here in 2008.   

Sam also believes the competition between Jive and traditional IT vendors like IBM and Oracle, “2.0″ pure play vendors and CMS providers will intensify in 2008 as the market gains more traction. 

Clearspace is also often compared to Sharepoint, so I asked Sam what his take on competition with Microsoft was.  Sam argued that Sharepoint, although it has a lot of great features, is more file centric.  Clearspace, on the other hand, is focused around collaboration.  In this way the business driver is different between why one company would buy one product over the other.

In Conclusion

Jive Software will continue its incredible growth in 2008 and will be more widely recognized as a leader in the Enterprise 2.0 space.  I think this growth might also attract larger enterprise players to consider acquiring Jive to gain a stronger foothold in the market.  Keep an eye on Jive in 2008.

No, this is not another post about combining social bookmarking and enterprise search. Instead I wanted to highlight how the social dimension of enterprise search - the search terms people use and the links they click as a result - can add to the effectiveness of an enterprise search solution.

The idea is simple:

1. Capture “fruitful” search queries - queries that cause a user to actually click a search result.
2. Capture the link, title, query and timestamp for each search result a user clicks. This can be done by re-writing the URLs to post to the search application first before redirecting to the original link.
3. Display the number of times a document has been viewed (”views:5″, as is the case with the first document in the screenshot). Documents that are viewed more than others tend to be more helpful, and this information can be useful when determining what to look at.
4. Massage the search statistics so that popular search terms are displayed in a “Search tag cloud”. This lets the user knows what the enterprise is looking for and helps create stickiness.

“Rabble” is a simple proof of concept that we developed in Ruby on Rails, and we could probably do a lot more with it. It integrates to a Google Search Appliance on the backend, and I’ve discussed how to do this integration before.

Interestingly, much of the information captured by Rabble exists inside the search appliance, and yet there’s no API to access it. Hopefully such an API is on Google’s roadmap, as information about user behavior can go a long way toward adding a valuable social dimension to enterprise search.

I’m a Java and C# guy. I’ve grown to be very comfortable with the two languages and associated frameworks (J2EE, ASP.NET), and can write programs that at least compile in each without having to search through the internet for examples. Hence my hesitation to learn Ruby - the language required for me to indulge in Ruby on Rails. But everybody’s doing it, and I don’t want to be left behind.

I decided to build a Ruby on Rails-based enterprise search application leveraging the Google Search Appliance (GSA) REST API. My aim was to show that A) Ruby on Rails is an agile framework leading to quick application development and B) the extensibility of the Search API (being that it can be leveraged from virtually any programming framework).

Here’s what I did:

I created controller class called Search Controller that manages the API invocation. This is done in an action handler method called on_search. This method invokes the GSA API, then converts the XML response into a REXML::Document object (part of the Ruby on Rails library.

url_escape is a nifty little method I found here that converts a search term like, say “technology integration” into “technology%20integration”. If you don’t do this things will break. params[:query] contains the search term the user enters into the search box on my search.rhtml page. Last the @search_results object is stored in the session and is a container for a collection of search results plus some global information about the search (like result_count and search_time). This object is bound back to my search.rhtml page to display the search results.
Next, I had to pull relevant information out of the XML response and add it to user-friendly objects that are then used to display the results on the view:

This method leverages ‘rexml/document’ to parse XML, i.e. search_response.elements[”GSP/RES/M”].text. “GSP” is the root node in the GSA XML API response document, and in this example I’m pulling out the result count, appropriately called “M”, inside the “RES” element under the document root. Parsing continues where I iterate through each search result, pull out the relevant information (snippet, url, title), add it to a SearchResult object, then add said object to the results collection in the SearchResults object (which, again, is stored in the session).

That’s it. In two quick and easy methods I can invoke the GSA XML API and parse its response into usable objects that I bind to my view. There is a lot that I’m not doing (i.e. good error handling), but I’ve at least proven what I wanted to. I’ve done this before in Java, and it took me less time to do it in Ruby even though I was learning the framework as I went.

I love Ruby on Rails.

I was searching for a Google Reader notifier the other day when I stumbled across Google Alerts (I ended up using this firefox extension for the notifier). I read the FAQ and could instantly see the value something like this could add to the “Signals” aspect of the Enterprise 2.0 SLATES meme. Here’s how it works:

1. Enter a search term for a topic that you’d like to be notified of (i.e. “Enterprise 2.0″).
2. Select how often you’d like to be notified.
3. Google will then send you an email with content items pertaining to your topic (videos, blogs, news articles etc.).

Very simple. Very powerful.

Within the enterprise, search is a very under-exploited capability. Why not take advantage of enterprise search and augment the signals capability to do exactly what Google Alerts does - contextual notification. Instead of creating an RSS subscription to the tag “marketing” or to a knowledge worker’s marketing blog, why not let the search engine do the work and determine what is “marketing”? In this way the user does not depend on other user’s tagging ability or new blog posts on the topic. And the powerful algorithms already trusted to deliver relevant search results will be the same used to keep the knowledge worker up to date on a topic in near real-time.

I don’t generally write technical posts, but the geek inside me wanted to share some insights into how to “mashup” Google Enterprise Search and Social Bookmarking. Here’s what you’ll need:

• A Google Mini or Google Search Appliance
• Scuttle - an open source, delicious-like social bookmarking application
• Xalan - a Java-based, open source XSLT engine

The Value Proposition
The idea behind this is this: when a user performs a search, each of the results on the page display social bookmarking information (tags and “saved by” count) if that URL has been bookmarked by somebody within the enterprise. This helps the searcher make an more informed choice when deciding which content to look at. If somebody else inside the enterprise has found a relevant content item to be helpful then perhaps the searcher should look at it first. It also exposes the searcher to others within the enterprise who have a mutual interest in the content being looked for.

Technical Mumbo Jumbo
Out of the box the Google Search Appliance provides a great amount of flexibility in modifying how search page behaves and feels. This is done through modifying the default XSLT (which produces a UI nearly identical to google.com). So, ideally all I’d have to do to include scuttle into the search results is use the document() XSLT function invoke a scuttle API that returns XML data about the URL (including the tag list and saved by count). I could then aggregate this XML with Google results XML displaying a seamless result to the user. Unfortunately the Google Search Appliance XSLT engine does not support the document() function, so I’m left to run an external XSLT engine - hence Xalan.

So, here’s what I did:

1. Downloaded Xalan and made some minor tweaks to the “SimpleServlet” demo application (class and package name change, modified the configuration to use my XSLT and invoke the Google Search Appliance to retrieve the results in XML format).
2. Packaged the modified version of the “SimpleServlet” and deployed it on my Tomcat instance.
3. Copied the Default XSLT style sheet from the Google Search Appliance, and modified it starting at line 2398 (the XSLT template for a snippet) adding code to invoke the Scuttle API and incorporate tags and saved by count at the bottom of the snippet. Saved the XSLT and bundled it with my “SimpleServlet” war file.
4. Copied the scuttle “posts_get.php” API and made a new API that returns bookmark information for a given URL.

That’s it. Users now access my custom web application to perform enterprise searches (instead if using the default GSA frontend), but so far so good. Hopefully one day Google will support the document() function so we can do integration like this using the XSLT engine on the appliance. That would certainly make life a lot easier.