Some News and DocRead by Collaboris Review

April 3, 2013

You might be wondering why I haven’t posted much technical stuff lately, truth is I have been busy with work and my other Community site. As many of you know I co-founded the SharePoint-Community.Net with a few other SharePoint people. One of the fellow founders who I have got to know very well is Mark Jones. When Mark isn’t spending many an hour embedded helping me with the community he is working on his other passion – DocRead for SharePoint. As both a thank you and also because I am an inquisitive guy I asked him for a download of DocRead so that I could road test it and write a review. So here we go.

What is it ?

DocRead allows you to assign documents (stored in SharePoint document libraries) to groups of users. Once sent out you can then monitor who has and hasn’t read them via a set of reports which are all accessible from SharePoint pages. Collaboris market it as a system to help distribute company policies, procedures, employee handbooks and so on, but really, this could be used for anything. Project documents, User Guides, Financial Results, Company Newsletters, etc. In fact, if you have a document that needs to be signed-off or even one that’s a ‘recommended’ read then using DocRead makes this a very simple task.

So, here goes this is what it’s like to use right from the install to an end-user using it.

Installation

DocRead installs via a standard windows installer, which as far as I can see is responsible for deploying a few local files and 3 Farm Solutions (WSPs) into SharePoint :

The installer takes a minutes or two to run, and also recycles your app pools, so do this out of hours. It’s a pretty smooth experience though and once it’s complete you end up with these WSPs in your Farm :

Configuration

Now the WSPS are installed into SharePoint, next up is to configure it. After installation the new menu in Central Admin looks like this :

SQL Databases

What’s really interesting is that when you first configure DocRead you need to go into the ‘Database Settings’ screen and give it the name of 2 Databases which get created on the SQL server hosing the SharePoint Farm. As follows :

When I asked why this is the case, mark pointed me to their ‘DocRead Architecture’ document : http://spvlad.com/Z5BL6x Within that there’s a section on ‘DocRead Data’ which states the following :

Roles

DocRead uses a top-down approach to when it comes to configuring. (e.g. the Farm Admin does some configuring, then hands over to the site collection admin who then hands over to the Site owner and so on..).

The following roles are required carry out the following tasks :

Farm Admin

· Decides which web applications DocRead will installed upon on (e.g. Intranet, MySites, Collaboration, Projects, etc)

· The frequency of the timer jobs (DocRead has 3 to do various processing like finding differences in audiences and groups and tasks processing)

· And where to install Reporting. I looked into this and DocRead uses Telerik for their reports, which is deployed as a web app feature. This is optional, but I think reporting is the best part of the product.

· Configuring messages (such as Ts and Cs)

· Viewing logs – all the error and informational messages get put into the DocRead database.

· Licensing – you can view full details of the license key, plus insert a new key as required.

Site Collection Admin

Now that DocRead has been deployed to the parent Web Application, it’s up to the Site Collection Admin to do one thing
Activate the DocRead site collection feature – that’s it,

Site owner

Once the business have decided (and I stress business as they will be the ones to use DocRead), which sites they want to use DocRead on, it’s upto a person with “Full Control” permissions (usually the site owner) to activate DocRead on that site.

Once they do this they are then able to do the following :

Attach DocRead to one or more document libraries it the site

· Configure other settings such as whether to “Force View” document

· Configure a group who will be “DocRead Administrators” (can manage, view tasks and process)

· Configure a group who will be “DocRead Publishers” (can send out documents out to groups of users with DocRead)

· Add the DocRead Web parts to pages in SharePoint. These will probably be high hit pages (like home pages) so that you users are alerted as soon as they goto them.

DocRead Administrator

When playing with DocRead as someone in the group as specified as DocRead Administrator, I was able to :

· View Reports (to see the status of the tasks in that site)

· View Site Reading Tasks (also delete them)

· Process Reading Tasks (this allows you to create tasks that have recently been assigned by a publisher)

DocRead Publisher

· The person in this group can assign a document to a group (via edit properties).

Sending out a document to a group of users

This is very straight forward – all you need to is go to the ‘DocRead site Settings’ screen and ensure you doc library is added into the list. Then, when this is done find the document you want to send and pick some groups or audiences. You also need to specify how long you want users to read the document before it’s overdue. At this point, things turn red in the web part and overdue emails will be sent out.

One gotcha here is that you need to be a member of the SharePoint group that you set up as ‘DocRead publisher’. If not these columns can’t be set. So for example, if I am not in the ‘Approvers’ group I can’t send a document out with DocRead.

Emails

This confused me at first, but then if I only had read all the documentation! Email isn’t sent out using SharePoint which answered some of my initial confusion. Emails are actually sent by a windows service and that is configured by a Windows Application. I wasn’t quite sure why they built it in this manner so I emailed Mark to ask and he replied :

“We have built it this way for two core reasons :

1. Performance. DocRead is installed in some very large organizations who have a large number of documents and large number of users. To send out 1000’s of emails (on a daily basis) isn’t something you want your SharePoint servers to necessarily be doing.

2. Licensing. We didn’t want the customer to be forced to purchase another SharePoint server license, so we made it work completely independently from SharePoint on normal Windows kit. Having said, that if you want to run the service on a SharePoint server, this is also completed supported. (a lot of customers choose to do this).”

SmartMove

If you look on the DocRead web site you will see ‘SmartMove’ being mentioned quite a lot. Mark was also very insistent I check it out! So what is it ? It turns out that SmartMove is VERY cool! It is the bit of tech that allows you to do this …

1. Assign a ‘Required Audience’ called ‘Health and Safety Users’ to a document called ‘Health and Safety Guidelines.doc’ and give them 36 days to read and confirm.

2. Let DocRead create new reading tasks for everyone in the ‘Health and Safety Users’ group.

3. Some users confirm.

4. 6 months later a new starter joins the company and gets put into the ‘Health and Safety Users’ group.

5. DocRead realises there is a new user who has not been asked to the read the ‘Health and Safety Guidelines.doc’, so it creates them a new reading task and gives them 36 days to read and confirm.

Imagine, just how cool that is ? Once you have configured your documents to groups or audiences, DocRead will monitor the group or audience for new entrants and ensure they are kept in line with company policy. This feature alone sells it for me!

I also tested to see what happens if you remove a user from the group…If this happens the user isn’t any longer required to read that document (and a negative receipt is created).

Reporting

One major part of this puzzle is around reporting. Once a publisher has sent out tasks to their employees they really need to be able chase and track who has read what. I imagine this would be especially important for documents that go to all employees in large orgs. DocRead ships with reports all pre-configured via one of the menu items in ‘Site Settings’. Once you click Report you are taken through to a page that allows you to view reports. As you would expect, the reports can be printed, exported and filtered and so on.

One nice feature would be to be able to create new ones, but there isn’t a way. However, I also asked Mark and he informed me that they can create custom reports if needed or a customer can hit some of the views in SQL to dev their own in something like SQL Reporting services.

Receipts

I noticed that when a user confirms a document, a new icon appears on the popup saying ‘View Receipt’.

This receipt shows that a user confirmed reading a version of a document at a certain time (think of it similar to an outlook receipt). Receipts are also accessible from a report by DocRead Admins. There is also the concept of a “negative receipt”, which will get created if a user doesn’t confirm a document. For example, if the document is deleted then they can’t read it any more. Not sure of the reason for negative receipts, but I guess there’s some auditing requirement that it meets..

Web Parts

There are several web parts that ship with DocRead which are split into two categories, tasks and charts. The tasks web parts show various views of the current site tasks, such as all tasks for the entire site, or a web part that shows all of a user’s tasks across the entire farm. The latter seemed the most appealing to me as this means you could put the web part on a user’s MySite and then allow them to see any tasks that had been allocated across all sites and site collections in the entire farm. Querying and showing content across site collections boundaries is usually a real pain, so this is a nice feature! Doesn’t matter where you have send the tasks from as the user can see them all in one bucket…

You would also more than likely place this web part on your Intranet home page so that users can immediately see they have some tasks to do.. Here’s what it looks like :

The other set of web parts are the charting web parts which give a visual way to see the break down and status of all the tasks in that site. These would be good on home page of the site in particular so that the publisher can see what’s happening.

Some fun scenarios

Being the admin I am – I decided to try some tricky stuff out to see if DocRead threw a wobbly and it held up really well. For example, if you assign 5 groups to a document to read and one person is in 4 of those groups, this still works fine. The user only sees 1 task but 4 are created behind the scenes. When they confirm – all the docs are confirmed. I also tried assigning 5 documents in different libraries, created the tasks and then deleted the libraries containing the documents (evil I know). At first the tasks remained then I noticed they got deleted. After more investigation, I noticed negative receipts were created. I asked Mark how and he mentioned that a Central Admin job synchronises what’s in SharePoint with what’s in DocRead. The other cool thing, if you restore the libraries then run a feature at the site level, back they come!

DocRead for the end-user

The last piece to cover is probably the most important. How does DocRead look to the end-user. The end-user will see and interact with DocRead by the following means :

· WebPart placed on a page in SharePoint

· Via one of the emails sent out to the user.

· When navigating to the document library containing documents that are configured with DocRead – there’s a new menu on the Ribbon.

Regardless of the ways to see the tasks, you will always finally end up with a ‘popup reading window’ which gives the user the ability to read about the document, see information about the task and more importantly be able to confirm the document. To be honest it doesn’t really require too much explanation – it’s pretty straight forward and looks like this. Once they click the ‘view document’ the button is enabled.

Summary

Overall, I have got to say I mightily impressed and I think it’s an awesome solution to have in your SharePoint toolkit. From an Admins point of view I really like that they have thought about performance and security as the last thing you would want is this tool on all libraries in use by everyone. I am also glad Mark pointed me in the direction of Smart Move as this really is ‘smart’. It’s outstanding to think that you could send a document to ‘all staff’ and then as users join or move around, DocRead will always keep them up to date. That is a huge time saver. If you have any more questions check out the Collaboris site or email Mark himself!

That’s it for now, and don’t worry, I have some really cool and useful SharePoint articles coming up!

Leave a comment and don’t forget to like us on Facebook here and to follow me on Google+ here and on Twitter here for the latest news and technical articles on SharePoint. Also, don’t forget to check the SharePoint Community Partners list for other great SharePoint Sites, and vote for my blog if you like my content!

Uncategorized