-
Upcoming
Live Online Workshops- Excel and SharePoint: I didn’t know you could do that!
- Easy Tabs Interface - Simple SharePoint Navigation for Complex Information
- Train the Trainer: Materials and Resources for in-house SharePoint Training
- Become Your Company’s SharePoint SuperStar!
- Hack SharePoint Web Part Displays with XSLT
- Business Solution: Health Care Case Management
- Killer Calendars in SharePoint
- The Basics of Content Types
- Business Solution: Create a Compliance Report Intake System in SharePoint
- Business Solution: Manage Input with Dynamic Feedback Forms
- Live Blogging at SharePoint Conference 2009
-
Ongoing Series
-
Authors
-
SharePoint Resources
- Bits of SharePoint
- Codeless Solutions for SharePoint
- Get the Point
- Innovation Matters
- Path to SharePoint
- Paul Galvin
- SharePoint 911
- SharePoint Blank
- SharePoint Blogs at SharePointU
- SharePoint for Non-Developers
- SharePoint Forums at SharePointU
- SharePoint Screencasts
- SharePoint Use Cases
- Social Media Talk Tweets
- The Sanity Point
- The Weekly Newsletter
| Weekly Newsletter Signup |
Jan
30
Diarrhea of a worm
I was walking my six year old to school this morning when he started shouting at me about this incredible book he was reading at school, “Diarrhea of a Worm”. As he continued to describe in glowing terms the story line, I realized he meant “Diary of a Worm”. I guess a little malapropism never hurt anyone, except maybe the worm.
It reminded me of why people are having a problem with using SharePoint when they first get started. The only context they have to relate to when storing information is the folder. In their mind, a Library is just another type of folder storage mechanism.
“So what’s the big deal?”, they say to themselves, “just another place to store files. I’ll create some more folders in here.” And off they go, replicating the same problems they have on their file server.
One of the first steps in getting End User buy-in is helping the user understand the new paradigm shift: A library is not a place to store folders, it is a way to organize your files into large chunks of information that can be sorted and filtered for quick access.
That’s the short form. John, Nicola and Lee will be adding more context to this in their articles, but as a Site Admin or Site Collection Admin, this is one of the most important concepts you can impart to your audience.
Diarrhea is not a diary, and a library is not a folder.
Mark,
As usual, this is a great object lesson for the world of SharePoint — and you gave me permission to say “Diarrhea is not a diary, and a library is not a folder.” That should create some interesting discussions here at my organization!
Chris
Trying to get people to see the potential of Sharepoint librabies, to use meta tagging and views is not always easy. The folder for many is a comfort zone that they undersatnd but as we all know it brings problems. A lot more of my work in the UK as a consultanthas developed from Technical to change management.
when we can use folder? or just keep on create the library to manage as folder ?
nsp – not exactly sure what your question is, but the only time we suggest to our users when to create a folder is when they want to manage permissions to a group of items within a particular library. They will still use metadata for organization/filtering, however, the folders provide a level of permissions management which otherwise would have to be done with multiple libraries.
Does anyone else do the same?
James – Chris Quick and I had a discussion on this a while back. We are all in agreement: the use of folders to manage blocks of documents needing specific permission levels is one of the main uses of folders. — Mark
As a follow-on to nsp regarding the use of SharePoint libraries i.e. how many is too many?
One major issue we have is the migration of the current file system into SharePoint libraries.
There isn’t an easy way to migrate these documents into libraries without creating a lot of libraries as the folder tree can be 7 or 8 deep. There is only so much information a view can group/sort/filter by. Also, there is user familiarity with the current structure which would be lost.
I fully appreciate the use and power of libraries, metadata and library views grouping by different details but the complicated document structure that we are inheriting does seem to make this task very difficult without resorting to 100+ document libraries at a minimum.
Are too many libraries a recipe for disaster or is it a sensible option for this type of thing? Additionally, we are writing a migration tool but are there any open-source/off-the-shelf options that allow for mapping from file system to document libraries, control of content types and control of setting up the content type data?
Many thanks from my ulcer