Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

"best practice" document for Sharepoint?

  Asked By: Taylor    Date: Feb 10    Category: Sharepoint    Views: 1229

From my brief look, I am thinking:

- Subscriptions may not be that useful
- Remove "Documents" from the root workspace view
- Make a single webpart to incorporate a list of departments,
with links to categories for depts not interested in their own dash,
and a link to a sub dashboard for those that do
- I need more than the p3 1gig server for the 100 users I am aiming
at?
- The navbar need alot of rework to make it look less messy

Is this a good start?
Are there any other practical suggestions you can make?

I am finding that the document management part (although the approval
system in pretty simple) is the meatiest part of the prodcut.

Any thoughts however controversial gratefully recieved.

Share: 

 

7 Answers Found

 
Answer #1    Answered By: Aastha Tatpatti     Answered On: Feb 10

Some thoughts in response:

1. Subscriptions are only useful when they are part of the culture of
information exchange in an organization. Like anything else in SharePoint
(or other knowledge management solutions), the function has to be made
functional for it to have any meaning.

2. Documents? Do you mean the document  Library dashboard? Not sure what you
are getting at there.

3. Ditto on the department / categories  comment. Not sure what you mean.

4. Performance depends on usage entirely. Whether you have 20, 100, or 1000
users, the real key is how much traffic the site will get. Microsoft has
guidelines but I have not seen any definitive benchmarking out there.

5. Messy navbar? It works for us, but this may be a matter of taste.

6. Make sure the users are well educated on the use of key words and
categories, and make sure you think long and hard before you set up the
system about what categories to use. Searching through thousands of
documents becomes more precise if the authors are smart about the document
profile.

7. Fully document the server  configuration and setup for the SharePoint
server - useful for disaster recovery.

8. Run msdmback frequently and back up the backup to tape or other backup
solution frequently so that if you have failures you can restore the server
quickly.

9. Be selective on the content sources you index with SharePoint: you can
index too much (so that searches return too much). One rule of thumb: index
only content sources that have document profiles on objects (like Office
files). If you index Outlook Email, then its advisable to profile Email
messages (I've heard of a company whose software product helps to do this
over Outlook).

I'd be interested  in hearing more 'rules of thumb' from the community.

 
Answer #2    Answered By: Roop Kapoor     Answered On: Feb 10

> 1. subscriptions  are only useful when they are part of the culture
of information exchange in an organization. Like anything else in
SharePoint (or other knowledge management solutions), the function
has to be made functional for it to have any meaning.

I guess I am wondering whether anyone has found subscriptions useful.
Public Folders in Exchange don't (from my experience) get used for
much else except a kind of overspill archive, or perhaps a central
address book and the like. Subscriptions just seem to add to the "on-
screen" clutter of the portal at first look.

> 2. Documents? Do you mean the document  Library dashboard? Not sure
what you are getting at there.

Yes I mean the document library. Its weird that the document library
takes you to:

Documents/Dashboards/Portal Content
(In fact anything thats off your root  gets added in there)
In Bill English's book, he talks about some users removing this
dashboard altogether as its confusing.
(Although I haven't worked out how to remove  any of the default root
dashboards like Search or Document Library yet)

> 3. Ditto on the department / categories  comment. Not sure what you
mean.

Well categories is a weird concept to me. I was thinking about
removing the categories dashboard, and having an plain HTML webpart
that lists the categories, and the dashboards that only some
departments want, and just having this list  under a "Departments"
heading. This way, users navigating the site just pick a dept from a
list, they don't know or need to care about the difference between a
category or a full dashboard.
I'm still not comfortable I guess with how the categories and
dashboard relate to each other. Perhaps I could rename "categories"
as documents, as I won't have any other sources of content except
uploaded documents  :)

> 4. Performance depends on usage entirely.

I agree. I think I am in a suck-it-and-see situation.


> 5. Messy navbar? It works for us, but this may be a matter of taste.

Part of me wants a navbar. So users can find home, quickly search etc.
It just feels weird that it always contains the sub dashboards like
subscriptions, that I may not use. I've removed it at the moment, but
I have a feeling I will need it back.
Can the Navbar be hacked/modified?

> 6. Make sure the users are well educated on the use of key words and
categories, and make sure you think long and hard before you set up
the system about what categories to use. Searching through thousands
of documents becomes more precise if the authors are smart about the
document profile.

This is one of the things that everyone tells you about Sharepoint.
We are going to have a meeting with all the departments assigned
reps, and the IT project management to make sure we get this right.
There are 7 departments, and I know they will want to curve up the
category space to match the folders, but their folder tree is about 8
deep, so I really want to persuade them out of this.
Not sure how to persuade them that:
Finance\Audit\2002\02 Feb
isn't a good category.
Perhaps under Finace, the sub category audit is sufficient with a
good document profile, but people minds will surely be fixed in
stone :)

> 7. Fully document the server  configuration and setup for the
SharePoint server - useful for disaster recovery.

Check.

> 8. Run msdmback frequently and back up the backup to tape or other
backup solution frequently so that if you have failures you can
restore the server quickly.

This doesn't happen often right? It is stable huh?
Exchange has always been kind to me. Is Sharepoint similarly solid,
or are their camp fire stories of it going down in flames? :)

9. Be selective on the content sources you index with SharePoint:

Im only doing uploaded docs, hopefully avoiding any indexing
complication.

> I'd be interested  in hearing more 'rules of thumb' from the
community.

Yah me too!

 
Answer #3    Answered By: Kelley Obrien     Answered On: Feb 10

My point of view :
1. subscriptions  are very useful. I prefer that to a "New"-part.
2. I think the document  Library should open immediately on 'Documents'.
I ignore the use of the Portal Content-link and the Personal
Dashboards-link. I also ignore the use of the personal dasboards tout court.
3. We should be able to hide without problem dashboards we don't use.
4. I miss a "Deleted items"-part ; would be very useful in case of
accidentically removing from documents.

 
Answer #4    Answered By: Ashleigh Neal     Answered On: Feb 10

More:

Re: 2: Got you. I agree with you and Marie-Christine that the Document
Library dashboard  should open directly on the documents.

Re: 3. It took me a while to conceptualize categories  as well, but after
thinking it through I don't find it weird. If you simply mirror the folder
tree in your categories, there's no point in using it. Categories are a way
of bunching together things that otherwise might not find their way together
because organizations are naturally divided in ways that prevent it. It's a
way of thinking across an organization, beyond departmental or divisional
boundaries. In a given group, say an IT department, there may be developers,
database administrators, technical support personnel, and network support
personnel all tasked with making a contribution to disaster recovery, for
example. They may upload their documents  in folders that belong to them (and
their division), but by using a category that crosses the document  library
structure, people can find information that may be useful to them they would
not otherwise discover. I think of categories as abstractions useful for
pulling information together from disparate sources.

So again, I would recommend against making categories equivalent to, say,
organizational boundaries. The Document Library structure can be usefully
architected to match divisions, departments, task forces, other group
structures.

Re: 8. We run msdmback via script once or twice a week at night, and the
server is backed up twice via tape backup with tapes going off site twice a
week. Even if SharePoint doesn't go down in flames, sometimes you might need
to rebuild the server  for data corruption issues, hardware issues, virus
issues, etc. etc.

 
Answer #5    Answered By: Mitali Panchal     Answered On: Feb 10

A couple of my thoughts...

Categories: If your categories  are a mirror of your file structure, then
you are not using them as the product intended them. Here is the basic
thought pattern: Content contributors (authors) generally understand
file systems and directory structures as well as how to navigate them.
Content consumers (generally readers) may not know your specific file
structure layout and therefore may not know where to start looking for
information. Enter categories... By using categories correctly, Content
consumers need not understand your specific directory structure to find
information. They can browse the categories and information that is
located across many directories and even data sources will be grouped.
If the file structure and the categories are mirrored, then sps is not
being used to the best advantage. Also note that it might is probably
not beneficial to categorize every document. documents  types or
information that is may be local to a group who knows and understands
the file system might not server  much purpose being categorized. I like
to think in terms of what a reader will be looking for and base
categories off that.

Finance\Audit\2002\02 Feb is not a good category. What might be a good
category would be Audits possibly with a sub category of the year.
Another thing to remember involves scaling out. A single
workspace/server can stand alone meaning it does not matter what
categories you have. Down the road you might end up with another
workspace for lets say the HR group. You now might be asked to index all
workspaces and you might find out that the same category is used
differently depending on the workspace. Here is the example I use:
Internal Development department has a workspace  and a category named
project management. It is used to denote various project related
documents of ongoing projects. Consulting Department has a workspace
and a category named project management except that this is used to
denote various project management techniques. What happens when the
organization creates a server to crawl and search all available
information? A search on Project Management now returns less accurate
results because it has different meanings. Something to think about
before hand.

 
Answer #6    Answered By: Wanda Petersen     Answered On: Feb 10

This prompts the question, if I don't categorise a document,
presumably that means it doesn't show up anywhere in the categories
dashboard or any subcategorys/dashboards?

If you don't add a category, can it still be found on searching?

I think its dawning on me the split between category and doc folder.
Doc folders can be used for "everything" that needs keeping safely.
And categorys are for widely available documents  that users of the
particular dashboard/workspace would need to be able to find, such as
HR policys.

 
Answer #7    Answered By: Eric Davis     Answered On: Feb 10

Yes that is more in line. Any doc that is in the sps datastore and is
published implicitly or explicitly will be indexed and searchable. There
are a few excluded docs for the system. Categories is just another piece
of data associated with the doc. Having a category is really just
another piece of searchable metadata.

Another "change" in how things are done when you start a SPS system.
Directory structure is usually done differently. With a file-based
system directories are create based on metadata. For example, I would
not be surprised to see a directory structure such as :
Finance\Audit\2002\02 Feb. What this is really saying is look  here if
you need audit info for the Month of February, year of 2002 and so on.
Most often this type of structure is there to allow users to find the
document. This is not always need on SPS due to the increased amount of
metadata. You might have a folder in sps for Financial Audits. Within
this, you would have a document  profile named "FinancialAudits" with
properties such as author, category, DateOfAudit and Title. Users can
easily navigate to the folder audit and view the metadata to pick the
correct file. There is not as much need to create an elaborate directory
structure that includes the metadata in the structure name. More
importantly folder structure in sps should coordinate common settings
such as security, versioning and approval routing which are maintained
at the folder level. Simply put most file based systems do not directly
translate into SPS folders and might not really need to thanks to all
the metadata available.

 
Didn't find what you were looking for? Find more on "best practice" document for Sharepoint? Or get search suggestion and latest updates.




Tagged: