For almost every scenario where we have implemented multiple Content Types  for documents, the next comment was if we can replace the “New Document” menu. The menu stops been practical when you have several content types on the same Library and it is definitely not suitable when you use SharePoint with a touch input device. I always wanted to implement a solution for this and I finally managed and here is a detailed description of it.

First of all lets take a look at the out of the box menu which is a split button showing the available Content Types.

SharePoint-NewDocument-Menu

My implementation replaces the out of the box split button with a standard button, while retaining the icon, tool tip and label for consistency and localisation. The difference is that when you press the button, a modal dialog appears showing you a list of available content types. Clicking on one of the Content Types will launch the relevant client to create a new document.

Immersive-NewDocument

The way the solution was implemented was with a Custom Action to replace the existing New Document button with JavaScript handling the press event to launch an application page as modal dialog. The list ID is sent as a query string parameter. The page itself has two elements; a ListView with an ObjectDataSource as its data source. So if you wanted to do any presentation layer changes you work exclusively in the application page. The ObjectDataSource has one select parameter of type QueryStringParamater. The ObjectDataSource then uses the ContentTypeSource class to retrieve all the content types for the list with the given list ID in the current Site in the shape of a ContentType class.

Some features I would like to add;

  • A search box to search for Content Types. The list of Content Types will be shorten to display results only.
  • Grouping of Content Types, potentially using a custom UI in List Settings to configure the groups.
  • Paging which isn’t too hard.
  • Caching so that we don’t rebuild the list every time. Distributed Cache sounded like a good idea but takes away compatibility with SharePoint Foundation.
  • Document Previews for those who have Office Web Apps or potentially using the document thumbnail saved by the client, if any.

The solution has some limitations/needs more work;

  • This was only tested and designed to work with Document Content Types. This wont work with InfoPath forms or List Items. I wont support those Content Types for now.
  • The dialog does not display the Folder Content Type (has its own button on the ribbon) nor hidden Content Types (just like the standard menu). This is by design.
  • The button registers to specific document library types e.g. 101 for out of the box document libraries and will apply to all of them in your Site. Since this is enabled using a feature, changing the scope to Site Collection will allow you to enable it on all sub-sites. Once again by design and provides the flexibility of enabling it to specific list definitions only.
  • The dialog does not close after you click on a Content Type. Working on that as top priority :).
  • The default save location in Office Clients is the root folder of the Document Library at all times instead of the folder you are currently in. This is top priority as well.
  • Styling is custom and doesn’t inherit a huge amount of styles from the theme engine and standard CSS classes in SharePoint. You can always use the custom CSS to modify the list of Content Types so not that high on my list.
  • Installation is a bit tricky; Need to add the assembly to the compilation/assemblies section which needs automation. This is top priority for me as well to reduce deployment complexity.
  • The code is based on a farm level solution and will not work with SharePoint Online.

I will be uploading the solution project to codeplex soon.

Advertisements