SharePoint in-a-box™ Business Solutions!

Archive for the ‘Blogs’ Category

As a SharePoint developer, you often have to struggle with certain platform limitations. One of those limitation is the fact that the EditControlBlock (The list item contextual drop down menu) does not support menu items display based on server sided conditions.  For example, you cannot do something like say: only display this menu when the document has a metadata value of “approved” in a specific column.

As a SharePoint product developer, this is a major problem since we have, to date, 11 products that sit on top of SharePoint some of which use this contextual menu in order to display available features to the end-user.

Let’s  take as an example render-It, a document transformation product that allows documents like doc or docx documents to be transformed in another format like pdf, html etc… Everyone will agree that this “rendering” menu item should not be displayed unless the current document meets the requirements for the transformation.  Some people on the web have taken an approach where they modify or override the core.js functions and add their own logic. This was not an option for us since we wanted a “non-intrusive” way of adding our logic to existing functions.

So instead, we used the reflective nature of the JavaScript language to “hook” up to existing core.js functions and modify their parameters in order to add our own menus at run time by making some ajax calls. This preserves the original core.js functions and prevents bugs due to possible upgrades or changes Microsoft might implement in the core.js.

This nifty little trick allows us to make an Ajax call to the server at run-time in order to validate if a specific menu item should be displayed for this specific item in this specific context. It makes the end-user experience much more enjoyable by not having 5-6 menu items that will give you an handled error message after you click on it like ‘this action is not valid for this item”  which is very unpleasant.

The result is a much more intuitive editcontrolblock menu with menu items available only when specific feature requirements are met by the current item, security, type, metadata etc….

In a perfect world, in the perfect document management system, there would be no folders. The windows OS has trained end-users to use folders in order to classify their information. Whether it is in a local drive or a network share, today when you are looking for a place to save your information, you are looking at finding the correct folder location.

Document management –capable systems such as SharePoint are able to abstract this folder hierarchy with the use of metadata. But what is metadata exactly? As always, I turn to my trusted friend Wikipedia for an answer: http://en.wikipedia.org/wiki/Metadata .  

The problem with metadata is that users with years of folder usage often have trouble adjusting to new ways of classifying their information, as they say, old habits die hard… This is why in many document management system implementation you will find the same old folder structure you had on your old network drive literally copied over to the DMS¹. 

But DMS¹ are capable of so much deeper and complex classification schemes, it all comes down to how you want to retrieve your information. I could go on and on about the different ways to implement a taxonomy in your  DMS¹ , and maybe I will in another article, but for now, let’s focus on what Replicate MD can do to help take a step in getting rid of our old folder habit.

Let’s take a look at a pretty common business scenario:  project management.

The typical document management implementation for project management would look something like this: A project management site or area, project document lists based on either clients or even projects and inside those lists you will have a folder hierarchy defining the rest of the relevant information like project name, project number etc. I can’t stress enough how wrong this approach is, but since most users are used to this and change is hard to implement, it might be the only way your users will adopt the new DMS¹.

Now that we have accomplished our first step, which is to make the users accept and actually use our new DMS¹, let’s see how Replicate MD can help us take it to the next level. Let’s go back to our folder structure where we have a list for all our project documents and our first folder level inside the list would be Client -> Project ID -> Project Name -> and maybe another folder level for each deliverable.

Client –
             |
                — Project ID –
                                        |
                                        — Project Name –
                                                                      |
                                                                      – Deliverable 1
                                                                      – Deliverable2 …

Now what would happen if we upload a document inside the deliverable1 folder and use the SharePoint search to find it? Chances are, when you are looking for this document, you don’t know exact keywords found in the content that would help you narrow down the search and find it. Comes to the rescue, metadata! If you implement metadata on your content, you now have a more efficient way to search for your information. You can now search for any of: project name, project id, client or even by deliverable.

Your new challenge is to get users to actually fill in the 10 new metadata fields required for this to work each time they enter new content in the DMS¹, let me tell you from experience, not going to happen; This is where Replicate MD does its magic. Replicate MD is able to take metadata values from its parent folders, and push them on the new document being created in the system without any user interaction. So your new document can inherit metadata values from deliverable, project name, project id and client at upload or creation time.

You now have the best of both worlds for your end-users, the ability to drill down a folder structure when creating a document, and the ability to retrieve information based on metadata (known information about the content they are looking for). Someone will not always know where a specific document was put in the system, or how to get there, but using a search with Reperio™ for example, would give them quick access to it.

(1)DMS – Document management System.

 If any of you have ever configured or at least try to configure SharePoint’s search, you know that this can be a difficult task. Trying to make sense of all configuration options (scopes, crawled properties, mapped properties, schedules etc.) can be a very tedious task, even for the more experienced SharePoint user.  This can be even more difficult when you have multiple web applications, with multiple site collections under your SSP that contains hundreds of columns to map. Trying to find the right crawl properties to create your mapping is anything but a fun experience.

Once you finally manage to configure the search service properly, you are ready to search… Wrong!  You now have to manually create an xml string with all the configuration options you would like to see in the advanced search web part!

Once you have gone through the effort of going through and selected your desired criteria for a search result in sharepoint you will not get the true results you are looking for due to the limitations in SharePoint out of the box.  The search webpart columns do not include lookup values, or calendars for dates, or people pickers or any of the dynamic controls you would expect. Users have to know the date format of the system to be able to search by date or, the exact value of the lookup field, there is no drop down for value selections… This whole experience has taken me back in the 1970’s back when programming was done using punch cards (ref: http://en.wikipedia.org/wiki/Computer_programming_in_the_punch_card_era) … that’s how backwards this whole process feels.

The search results are

-unstructured

-non-contextual

- unintuitive to say the least.

Metadata information does not appear and what else? No contextual drop down menu for actions on items?

With this in mind, I set off with my programming team to find a solution with a first set of features as requirements:

• Automated mapped property creation
• Dynamic search fields based on field type (lookup, date etc.)
• Private Saved searches
• Public Saved Searches
• Structures search results
• Contextual actions menu
• Sorting based on column values
• Fully Ajax enabled
• Ability to set a “result only mode” ( this is the ability to hide the search part of the webpart and show only results as soon as the user enters a page. for example, a page could be set to show all documents created by the current user in the past week as results or any other pre-defined search criterias)

The first task we tackled was to find a solution to the whole mapped property problem. Reperio ™ has an automated system programmed into it that will create and reference your mapped properties for you. From the administrative interface of Reperio ™, we included a column selection section from which you can pick your columns using the location where you created it ex: Site columns. This is very intuitive since you get to find your columns by the name you created it with, and the Reperio ™ mapping creation engine will do the rest for you.

But what about the search fields? As stated before, the search fields in the standard SharePoint advanced search webpart are very basic and have  no dynamic behaviours to help the user enter his values.   In Reperio ™ we included features that enable you to see things like lookup values in lookup fields. This means that the search field selection will actually be a dropdown field with the values of the lookup, and this even if the lookup is from another site collection, even if that site collection is in another web application! We also included a calendar for dates, a people picker selector for people and more. We have made each field dynamic in order to make sure it lets you enter values in the most intuitive way possible.

Another feature we made sure was available in Reperio™, is a way to allow the user to save his searches for later use. It also lets administrators create public saved searches which will be available for use by any user. This feature also comes with a nice little twist; the ability to set a saved search as the default search of a Reperio ™ webpart instance in a page. This is a very powerfull feature as it lets you create list- like views, on content anywhere in your SharePoint farm, think Content Query Webpart on steroid.

Our next challenge was to change the way search results are displayed. We felt the “google” like results were not the best option when it comes to content management results. So we opted for the structured search results, which show the results in exactly the same way items are displayed in a SharePoint list, along with columns / sorting / contextual menu actions and more… The contextual action menu is actually called the “EditControlBlock” in SharePoint technical terms. The menu we provide is the exact same menu, which will run in the context of the item and even show your custom menu actions if you have any implemented using sharepoint features.

 You can watch the demonstration video of Reperio ™  here:  http://www.youtube.com/watch?v=ipDOhsI9A2k

Alcero makes integrated SharePoint solutions meant to enhance existing SharePoint functionalities, and fill the empty spaces left in the document and records management aspects of the SharePoint platform. If you are not familiar with SharePoint, there is a nice little video called “SharePoint in Plain English” .

 Link to the video: http://www.microsoft.com/video/en/us/details/76e8d3af-c2bd-42a6-bb12-befcbd041bf1.

Over the next few weeks, we will be posting a series of articles, one for each Alcero product. In these articles, we will  explain the reasoning behind the product functionalities, how and why they were implemented in a certain way, and which SharePoint functionalities we are enhancing / implementing.  We will go over product functionalities using real life scenarios and discuss certain SharePoint limitations, and how our products  remove those limitations and  allow for a more robust content managment solution using SharePoint and Alcero Products.

Please come and follow us and discover all the latest and greatest about our SharePoint in-a-box solutions!