SharePoint... is a Web Services interface for my app worth it?

Question

I'm hoping to hear from a cross-section of folks who have SharePoint installed at their site. I'm trying to decide whether to have users just use the web-based interface to check-out and edit my application's files, then rely on them being sophisticated enough to know to go back to the SharePoint web interface and perform a check-in.

My presumption was that for the average organization out there using SharePoint, this would be incomprehensible to a good percentage of users. So, I began working on using SharePoint web services from within my application, so that users could open files, edit them, then check them in (optionally) at file close time -- all from within my app. However, my initial estimate of the development time to accomplish this fell short. So now I'm at the point of wanting to do some cost/benefit analysis.

How quickly and naturally do most users "get" the check-out/edit locally/check-in cycle of SharePoint?

Answer 1

My experience with the whole Checkout-edit-Check in process has been quite negative. It never works with a large group and you always get people complaining that the file they want is checked out. And we've especially had problems with Sharepoint 2003, I don't know if its any better in SP 2007

Answer 2

As OTisler mentioned, it's somewhat of a mess in Office 2003. The story is in fact much better in Office 2007, as Word, Excel, PP, etc. are all MOSS-aware, and reflect it in their menus, information bars w/ MOSS metadata, etc.

FWIW, I've done a few projects where a large (> 1,000 users/site) userbase was interacting with it, and the biggest problem was "he/she has my file checked out!" It's just a matter of educating the users that the answer is to call the offending user, not the help desk.

Answer 3

In some situations, office will create an implicit checkout. This definitely throws users and they have some difficulty correcting this.

I really cannot help with the cost/benefit analysis on this one, but I do know that users consitently take a while to get the issue. When dealing with a large organisation, it is definitely worth while limited the checkin feature of libraries to only those libraries that require it.

Answer 4

Our staff (about 40) used VSS to manage courseware development for the Air Force. We transitioned to SharePoint 2007 and Office 2007 last year and experienced a few problems, but none insurmountable. Mis-configured browsers and poor network performance had the most negative impact on user experience. Since everyone already had experience with the whole check-in/check-out process, it was mainly bringing people up to speed on how the process worked in SharePoint.

Regardless of experience level, there's one simple pre-requisite: Training, training, training! That's the key to happy customers. Establish reasonable expectations and realistic schedules for implementation. Let them know what's coming and why, then train them properly on how to use the product.

For our 300+ Air Force users (external customers), we started to see rapid growth in usage at the 6 month point. The key is to identify and involve early-adopters as technology advocates at all levels of the organization. Let them do the selling of benefits to their peers. Adoption will be slow at first, but pickup rapidly as word gets around.

Get the system stable and let your customers become comfortable before your begin piling on the features. If your system or application is percieved to be unreliable or overly complex (training!) during the early phase of deployment, you may never achieve a critical mass of satisfied users.