Category Archives: Sharepoint
Saying Goodbye to Sharepoint Folders
Allowing the use of folders in document libraries is one of the more unfortunate decisions Microsoft made with Sharepoint. Our love of folders is born of familiarity; they’re something we’re used to, comfortable with, and unwilling to let go of even if there’s a better alternative.
But for anyone that’s ever tried to backup a document library or email a URL knows just how much of a problem folders can be. Folder structures find themselves inserted into the URL of every document in your library – giving you atrociously long paths that are often too long to be saved on a harddrive.
In additon to the above, use of folders simply fails to leverage the full power of Sharepoint. Far too many people leave behind cool features like views and metadata in favor of the ‘tried and true’ folder system – only to become a.) frustrated by the types of problems mentioned in the last paragraph, or b.) asking themselves “why am I doing this online when I can get the same folder structure in a network folder, with much greater speed?”
Read my lips: “No more folders.”
Remember when Gmail first appeared? People initially found it’s ‘conversational’ model of organizing email to be frustrating and unfamiliar – that is until they realized how great it is. The same can be said of the proper way of organizing Sharepoint content, which is NOT to organize documents in vast, deep nests of folders.
Instead of folders, you should begin to think about two things: Content Types and Views.
Content types allow you to define bits of information that can be associated with documents. Combined with views, which allow you to view cross-sections of your document libraries based on information in the content types, you will be able to access your information more quickly and effectively.
For example, imagine you have the following simple folder structure in a document library:
Penskey Project
Meeting Minutes
Contracts
SLAs
Manhattan Project
Meeting Minutes
Contracts
SLAs
Instead of using folders, you could create a content type with two columns: Project and Artifact Type. You can then specify the project (Penskey or Manhattan) and the Artifact Type (Meeting Minutes, Contracts, SLA) at the time you upload the document. Finally, you can create any number of views in that document library so you’ll be just one click away from the documents you need. Create a view to show all Manhattan documents, another to show all Penskey Meeting Minutes, and another to show SLAs from both projects. You can imagine how this could be very useful when you have deeper folder structures.
Of course, creating content types takes a little more time up front and forces you to think carefully about the way you organize information… but that isn’t really a bad thing.
When it comes to Sharepoint folders, just remember: take a deep breath and let it go. Content types and views are the way to go in Sharepoint.
About the author: Chris Newman is a senior software developer at Counterpointe Solutions, Inc.
Is Sharepoint Matching Your Needs?
About a week ago, I came across an organization suffering from the ‘collaboration blues.’ It was looking for a way to automate document processing, search for and contribute to documents across multiple team members, create team workspaces, associate metadata with its documents, and expose all this functionality over Intranet and Extranet. This set of requirements practically begs for a solution in Sharepoint, which is what I was going to recommend to the organization. Imagine my surprise, then, when I discovered this organization already had Sharepoint.
This situation is not at all uncommon. MOSS 2007 and its successor Sharepoint 2010 contain a set of out-of-the-box capabilities so large that it can become a liability. This organization’s Sharepoint instance is not the first I’ve seen relegated to the role of a glorified file server – many groups adopt Sharepoint without realizing the true power of content types, site templates, workflows, and other features that make a mature Sharepoint implementation a truly beautiful thing.
If you have a Sharepoint instance that’s looking a little too much like a file server, then take a peek at some of the items discussed below. They could be the keys to transforming your instance into something truly useful.
Content Types
Sharepoint content types allow you to associate data with different types of documents. Your HR department may create a content type for resumes that includes additional information like skill sets, candidate location, rating, etc. It’s very convenient to have this type of data in addition to the resume itself, because once you’ve created the content type you can search for resumes with a rating of ‘Excellent’ or ‘Project Management’ included in their skill sets. Furthermore, you can restrict the range of data that can be entered into these fields by using custom lists (this will keep one recruiter from listing a candidate’s rating as “Great” while another prefers “Excellent” – governance, discussed later, plays a big role here.)
Site Templates
Most people know that you can create any number of site collections in a Sharepoint implementation, but surprisingly few realize that you can save a “model” site collection as a template. If you’re making subsites for a number of project teams that will have similar structure, lists, navigation, etc., then there’s no need to create them from scratch each time. You can simply create the first site collection to your liking, save it as a named template, then use it as the site template for the next site you create. All the navigation and web parts will be in place, providing your collections with a consistent look and feel.
Workflows
Sharepoint is capable of routing documents through approval workflows that can be customized as you see fit, and it can generally be done without writing a single line of code. If you require processing for your documents, make sure you check out the basic out-of-the-box Sharepoint workflows before you go looking for a custom solution. You may be surprised by the flexibility offered by the standard workflows.
Other Cool Things
- You can create timer jobs to execute according to a schedule. This is useful for a number of things, especially synchronizing Sharepoint document libraries with external systems
- You can configure document libraries to receive emails. You can associate a document library with an email address and automatically populate that library with emails sent to its pre-configured address
- You can create custom web-based forms using InfoPath. InfoPath allows you to create forms without using code that can be deployed to Sharepoint and made available to users through the browser. Form information can be saved into document libraries or manipulated in practically any way you see fit, all without writing code
Governance
Governance is, in short, the creation and maintenance of principles that guide the use and implementation of Sharepoint to that it becomes a reliable, consistent, and useful system for the people it’s supposed to benefit. Governance is to Sharepoint what laws are to a nation. Sadly, this most important part of the business of running Sharepoint is also the most overlooked. The result is Sharepoint implementations suffering from one or more of the following:
- A patchwork of loosely related and often redundant site collections
- Inconsistent look, feel, and navigation throughout the site collections
- Non-existent or poorly defined content types that make locating documents nearly impossible, resulting in deep folder structures within document libraries that effectively turn Sharepoint into a file server
- No guidance as to how to implement and deploy custom features and other upgrades
- Lack of SLAs that cause Sharepoint maintenance windows to clash with project deadlines, among other serious problems
- A Sharepoint implementation that people hate to use
If any of the above looks familiar to you, then you probably have a governance problem.
I could go on all day about the robust features of Sharepoint, but we’ll leave it at this for now. If you have any Sharepoint issues you’d like to discuss, feel free to email cnewman@cpointe-inc.com.
Evaluating Sharepoint 2010
In an effort to streamline internal business processes, among other goals, our team is undertaking a plan to internally adopt an on-site deployment of Sharepoint 2010.
We currently use Sharepoint 2007 hosted in the cloud by a third-party provider. This solution has worked well for a limited set of business needs, but a desire to extend it with custom features, integrate it with other enterprise applications, and have greater control over disaster recovery have prompted our team to evaluate bringing a solution on-site.
Our pilot will include a full-featured, two-server Sharepoint farm installed in such a way that it can be easily scaled to an n-server architecture that can take advantage of load-balancing and server clustering. The instance will be integrated with several internal applications – mostly HR-related – and then augmented with a number of out-of-the-box and custom features (principially in the form of workflows and timers) to make a number of our internal processes more consistent and efficient.
Sharepoint 2010′s increased mobile-friendliness allows the platform to detect mobile devices accessing its pages and redirect URLs to pages optimized for small screens and reduced bandwidth, and should provide easier access to collaboration tools and documents for our many staff members who are frequently offsite.
Finally, migration from our existing hosted 2007 Sharepoint solution is a great concern as we have used it extensively and have a fairly large amount of documents and other information stored there. Our hope is to perform the migration with the database attach upgrade feature of Sharepoint 2010, which (in theory) allows automatic upgrades of Sharepoint 2007 content databases to 2010 using commands in PowerShell.
