Those of you who are new to all the nooks and crannies of SharePoint need to develop a good audience and user architecture as well as a firm sense of how much memory you are using. On my first site I mistakenly gave permissions to people when they asked and began uploading any relevant document/file.
This was all done in the name of being a dilettante. The idea of creating a worthy alternative took over function. A much needed element to build true knowledge based foundations.
I covered what I did for lists and libraries using Data View and columns in My Cut Man post, but what to do with permissions and file sizes?
I thought that permissions and inheriting them to child sites would be enough. And it was for a while. My first site was a training and procedure repository. Read only to everyone except me, the owner. Manuals, help-guides and procedures were funneled to me to edit, update and upload.
But a funny thing happen along the way, people responded positively to lists and libraries and more than one team wanted to their own spaces and calendars. Since many teams collaborate it made sense to have them all children of the same department site. I soon found myself working too much between shared drives to upload all the content. It was then that I decided I was going begin a policy and train users to run their own libraries and lists.
Once I had the team selected I decided that there was too much risk to the overall site to give these users creation opportunities. So my training plan consisted of Basic Navigation, uploading and revising (in Standard and in Data Sheet view). This solution worked well until I began receiving space allocation emails. Since I had taken on more a SharePoint Architect/admin role, the tech writing within teams was suffering. Screen shots were twice the size that I used in the past and even though I explained the concepts of being selective about what to upload the Team libraries began to resemble dumping grounds of “shared drive land”; multiple versions, archaic file naming, etc. And worse yet, the dreaded subfolder began to resurface.
Thus rebuild 3.0 began.
The requirements were easy enough to follow. I wanted to create a series of tight resources spaces. Any procedure or training doc that was updated more than quarterly should be in done in a wiki or blog. That alone saved closed to 1 GB. Though it was not a easy sell at the beginning. So take note, Be careful when using terms like “wiki” and “blogs” as solutions when you work in conservative environments. I soon found out that “editable online doc” worked better. Since some companies block out anything that is mentioned as blog it did not help to call it that in the beginning. Again, to hush nay sayers I quickly added the costs of MOSS space by comparing multiple a MB word docs to a thinner wiki. Excel spread sheets (where deemed appropriate) were reedited and uploaded as a list.
Result so far so good. Teams needed be trained on wiki page creation. Since groups were already set up it was easy to enable their wiki use without breaking form.