Geeky Girl : document

Multi-stage disposition

JessMeats — Mon, 26 Oct 2009 09:10:00 GMT

I'm continuing my series of posts highlighting some of the new features in SharePoint 2010 by talking about one of the new document management features.

In Microsoft SharePoint Server 2010, it’s a lot easier to have document management policies that are broken into stages. In MOSS 2007, if you wanted to have a policy that had several different steps, you would have to write the custom workflows to handle it. With SharePoint 2010, when defining your policy, you just have to click to add new stages and set the policy rules for each one.

You can then use a combination of the out of the box policy actions and your own custom workflows. Simple!

If you buy MOSS 2007 with Software Assurance now, you’ll get the upgrade rights to 2010 when it’s released. There’s no better time to buy!

SharePoint for Document Management

JessMeats — Thu, 18 Jun 2009 17:39:00 GMT

Continuing my series of videos showing the capabilities of SharePoint as a solution for various business problems. This video shows some of the features relating to document management.

SharePoint for Search

JessMeats — Wed, 17 Jun 2009 12:37:00 GMT

This is the third in my series of videos showing how SharePoint can be used as a solution to a range of business problems. This demo shows some of the features that are designed to help SharePoint function as a search solution, such as basic and advanced search, people search and business data search.

Better with Office - Workflows

JessMeats — Mon, 01 Jun 2009 17:35:00 GMT

SharePoint has two levels of workflow capabilities. With Windows SharePoint Services 3.0, you get the ability to create your own custom workflows either with code or using SharePoint Designer’s workflow wizard. With Microsoft Office SharePoint Server 2007 standard, you get that ability still, but you also get some out of the box workflows for common tasks such as document approval and collecting feedback. These capabilities can be accessed from within Office.

One of the options from the Office menu is Workflows. When you select this option, you get a menu listing the various workflows associated with a document that can be manually started. This will include any workflows enabled over the whole SharePoint deployment as well as any specific to the document library the file is stored in. You can start any of these workflows from right within the Office document.

For the out of the box workflows, this will open up a window within Office to enter any required information, for example, the name of the person to approve the document. With custom workflows, clicking on start from this menu will take you directly to a SharePoint webpage for the workflow to initiate it.

Once the workflow has started, this will assign tasks to the appropriate people. These tasks will be associated to the document. When someone opens this document, SharePoint will check whether that person has a workflow task assigned to them. If they do, a notification is given at the top of the document stating the task and with a button labelled “edit this task.”

If the workflow is one of the out of the box ones, a window will open up within Office to complete the task, otherwise, you will be taken to a SharePoint webpage to complete the task.

So, if using the out of the box workflows, you can complete tasks from within Office without ever needing to open up a SharePoint page. With custom workflows, you can be alerted to tasks and directed to exactly the right place to complete your assigned tasks. You don’t need to check back with a SharePoint site to know what work you’ve got to do or navigate through task lists to do what’s required.

Users get to stay within Office as much as possible and so experience an interface they're familiar with. This can mean significantly lower training costs and much greater product uptake from within the organisation.

Better with Office - versioning

JessMeats — Thu, 28 May 2009 14:17:00 GMT

This is the second part in my series of posts about the benefits of combining SharePoint with Office. I’m going to talk about versioning.

Versioning is one of the major benefits a document management system has over a file share. A common scenario is for people to have a document stored in a shared network drive and all work on it there. They start off with one file and everything’s fine. But, after a while, someone will make significant changes or decide they’ve reached a point where they should save the document as a new file. So now they have version 1 and version 2 sitting next to each other in the same drive. This will often happen multiple times and different people may have their own naming conventions regarding new versions.

Pretty soon, there are several versions of the same document and it’s not always clear which is the most recent one. Someone might edit the wrong version and then you have a document with a later edited date than the one which claims to be the most recent version. When next someone wants to make changes, which version do they edit? It doesn’t take much to turn a shared folder into a hideous mess.

A good document management system will give control over these different versions, making sure that users edit the correct version but maintaining drafts as appropriate.

Within any SharePoint document library, you can turn on versioning. The setting options are for either major versions or major and minor versions. When versioning is turned on, each time you edit a document, SharePoint will save it as a new version. This means that all the older versions of the documents are maintained, so you can compare changes or go back to an older version if appropriate. But users who go to the document library will only see the most recent version. This means you get all the benefits of maintaining a history of previous drafts, but none of the confusion.

But what’s this got to do with Office?

Within the menu of Office, under the Server heading, is the option to view version history. This will open up a list of all the previous versions of the document. You can use this to see who made changes and when, as well as opening up those previous versions to compare changes or even to revert back to an older version if the recent one has been corrupted or altered incorrectly.

This version history is stored and maintained by SharePoint, but it’s easily accessible from within the Office programs.

You also get the option to publish new versions and add version comment from within Office. The following image shows the dialogue box given when you want to save changes back to the server. Users are asked to choose whether they’re saving a major or a minor version (assuming the document library settings are for both major and minor versions) and to add comments which are stored in the document’s metadata.

So users get access to this rich, document management functionality from inside a tool they’re familiar with. Users don’t actually need to open up a SharePoint page to gain access to some of the benefits the program can offer.

Better with Office - Metadata

JessMeats — Tue, 26 May 2009 17:59:00 GMT

What is metadata? The simple definition is that it’s data about data. In the case of SharePoint, it’s information about files and documents stored within SharePoint. There are some bits of metadata that are included as standard, such as who created a document, who last edited it, where in SharePoint it is and so on. You can add your own metadata as appropriate. If you want to have documents labelled as whether they’re confidential or not, or attach a next review date to official documentation, you can do so.

If you’re running MOSS 2007 standard or enterprise, you can set policies and rules across the whole of the SharePoint deployment. One example of this I’ve seen was a situation where the company wanted to label some documents as being key documents. So every document in SharePoint had this piece of metadata associated with it, which was a yes/no option stating whether or not that particular document was key. Those that were key were then displayed to the users through a portal page. What’s more common would be to create document types and to associate certain pieces of metadata to those types.

Metadata can also be applied at a document library level. This is true for WSS 3.0 and both levels of MOSS 2007. In a document library you’ve created, you can add a column by clicking on Settings -> Create Column. Then you will be given options to set about the data that should go into this column. These options are things like whether it’s a line of text or a number or a choice from a list. You also get the option of setting a default value, calculating the value from other values or setting the column as required. Once you’ve clicked OK, you’ve associated a new piece of metadata to this library. All documents created here or added to the library will now have this bit of information stored about them.

But what’s this got to do with Office?

Well, when you open up a file from this library in an Office 2007 program, you will see a Document Properties section in which to enter this information. This gives the user space to enter metadata, shows metadata already associated and shows which fields are required. This means users can enter information that’s used by SharePoint, without ever needing to go to SharePoint.

If you’ve set some metadata fields as required and the user tries to save the document without them, they will see an error message. This informs them what has happened, takes them to the Document Properties panel and highlights the problems. If data has been entered that’s incorrect (for example, text in a number field) this will shown by a red dashed line around the field. A red asterisk will show required fields that have been missed. The error message explains this formatting to the user so they will be able to see what has gone wrong.

Users can save documents straight to SharePoint document libraries from within Office. This all means that users can be making use of the document management features of SharePoint without actually opening up a SharePoint page to put information in. This makes the process of document management incredibly smooth and efficient, while allowing users to work in an environment they’re familiar with. It can cut down training costs immensely if employees are already used to Microsoft Office.

Check-out and edit in SharePoint document libraries

JessMeats — Fri, 14 Nov 2008 16:00:00 GMT

When I'm asked a question by a partner and feel that the answer is likely to benefit more people, I shall write a blog post about it.

The question in this case was regarding checking out documents from a SharePoint document library and editing documents, and why check-out and editing aren't the same thing.

By default, document libraries in SharePoint don’t require you to check out a document to be able to edit it. When you check out a document, a checked out icon appears next to it in the library and no other user can open the document for editing. This prevents multiple users editing the same document at the same time.

However, under SharePoint’s default settings, users can select to edit a document without checking it out. If the document is an Office 2007 document, then other users trying to edit it will be informed that it is being used by someone else, preventing issues with simultaneous edits. If the document is of a different format, this doesn’t necessarily happen, which can cause problems.

It is easy to change the settings of document libraries to force checking out before editing. There are plenty of help files and blog posts explaining how to do this, so I won’t repeat the information here. If check-out is required, then any user clicking to edit a document will be checking it out at the same time, without needing to explicitly say that they are checking it out.

The question I was asked was this: why isn’t required check-out the default?

It’s a good question. Given the number of sources I’ve seen that recommend getting users to always check out a document before editing, it seems surprising that required check-out isn’t the default.

There are two answers.

The quickest is that required check-out prevents users being able to edit multiple documents in datasheet view.

The second answer is that required check-out can make life harder for developers. SharePoint is a set of incredibly valuable tools in its own right, but it’s also a platform for developers to build custom solutions. In researching the answer to this question, I came across a few forum posts where developers were struggling to write custom workflows that involved editing documents that were in libraries where check-out was required. These workflows needed extra steps, extra code and therefore extra work. The workflows needed to include the check-out and check-in steps, which could sometimes cause conflicts with other steps in the workflows.

So if you, your company or your customer are not planning on coding any custom workflows, then maybe you should change the default settings to require check-out. On the other hand, think whether it would be easier to simply tell the users to always check-out first. You might be saving your developers a headache later.