One of the topics that routinely comes up with many of the clients I work with is the capability to move information currently stored on company file shares to SharePoint. (NOTE: The focus of this post is on user experience, but there are other factors to consider. Joel Oleson has a what not to do list that’s a valuable resource, and this post also has quite a bit of info on the discussion.)
You may be familiar with the morass that defines many corporate file shares: endless lists of folders and files. Many users, sick of scrolling to the middle, have figured out how to hack the default Windows sort order and you find folders named “@@ Sales and Marketing” and “00 Transportation” to force items to the top of the list. Of course, the advertising department now finds itself having to scroll and renames its base folder to “00 Advertising” – and the renaming wars are on. If you’re a SharePoint junkie, your first thought is “Gee, SharePoint offers a great solution to this!”
And it’s true. Specifically, the ability to tag documents stored in document libraries with metadata and to have that information be searchable, used in grouping and filtering rules for views, etc., makes for a compelling alternative to the unstructured file system mess.
At least in theory. And now to the point of my post.
From a user perspective, SharePoint is a great file system replacement when the collaboration performed by users is on single-file basis. Create a Word document. Share it. Keep track of the versions as multiple people edit it. Execute a workflow against it. Specify the metadata right inside of Word or Excel. The list goes on. My company uses MOSS heavily for both internal and external collaboration, and I perform this type of activity every day. It works extremely well.
Where I think the file system replacement argument is less compelling is when doing the other thing that most of us knowledge workers do on a regular basis: work with lots of files and move them all around. When it comes to this, the user experience that SharePoint offers is pretty rough. Oh, I know you can open a document library in Explorer view, that you can upload multiple documents at once, etc., but the metadata solution in those cases – keep the files checked out to me until I fill in all the required fields – makes it nearly worthless. (And metadata is one of the compelling reasons to use SharePoint, right?) Sure, I can drag 30 files into a doc lib, but now I have to go through each of the files in the SharePoint UI, choose “Edit Properties,” set the metadata, and check it in? That alone is enough of a barrier to cause many users (including myself in some cases) to prefer the good old-fashioned file share.
I think this is a solvable problem, but to get traction and gain user acceptance, the solution needs to meet some very basic requirements to replace the file share. (NOTE: Mike Watson has a good post on when SharePoint might not be the best storage solution, and I generally agree with him on the conditions.)
I intend to keep this post updated with new thoughts as they rattle in my head, and I’d value your feedback, as well, but here’s my start at a list of basic requirements. It’s most definitely incomplete now, but I want to keep a background thread running. Maybe someday I’ll have the time to work on a community project… J
· Speed. Nothing fancy here, but I think this is a big one. When I’m browsing network file shares, it’s just plain fast. Click on a column header to sort and it’s done. Drag items around, delete them, etc. It’s all blazing fast. SharePoint isn’t bad on a LAN connection, but it’s not competitive with the Explorer shell. It seems to me there’s certainly some ground to be made up with SharePoint by using AJAX for column sorting, for example. Even on the fastest connection, forcing the browser to render a page sets it back on performance. I think the SP team is on a good track with the Explorer view, but it still doesn’t compete from a performance perspective.
· Metadata Management. As I mentioned before, setting metadata on documents is brutal from a user perspective. One of the ideas I submit to clients is that when users are saving documents on the file system, they really *are* assigning metadata: the folder structure and file naming conventions that people put into place are really just pieces of metadata that could be better stored in another format. However, when I save a Word document in a folder and then go to save a second document, I’m now defaulted to the folder I just saved the last file in. Word is betting that I’m doing something similar to my last doc and I might want to save it there. Essentially, it’s defaulting the metadata. I know: it’s a minor point, but people make decisions about whether or not to use systems over smaller things.
· Working with Multiple Files. Explorer view allows you to move files around, but what about the ability to select multiple files and then edit the metadata elements that are common to all of them?
