Technical Writer

Whenever I meet other SharePoint users I always want to know what works for them.

Here’s what works in our company, and what doesn’t.  We use SharePoint 2003.

What works:

• Document libraries
• Revisions
• Issue lists
• Task lists
• Link lists
• Portal listings
• Office integration (sort of)
• Export to spreadsheet
• Web part pages
• Custom lists
• My links
• Surveys
• XML web parts.

What doesn’t work:

• Discussion boards
• Email integration
• Calendars
• News
• Check in/check out
• Alerts
• My Site.

We don’t use:

• Form libraries.

Document libraries

At least 80% our our SharePoint usage is document libraries.

It’s a constant struggle to restrict the number of libraries, particularly in Portal Server (SPS).  People want to create multiple sub-areas with a separate library for each, even when they would be better suited using one sub-area and one document library with folders and custom fields.  It’s a mindset thing.  Because Portal Server looks like a hierarchy, people can’t see any other way to use it except as a hierarchy.

Early on in our SharePoint implementation I let one group convince me they needed separate libraries for each type of process. 

Bad mistake.

They now have around 30 libraries, each in a separate sub-area, containing an average of three documents per library. 

In their defence, they maintain them beautifully, but it must be hard work.

They had a spring clean of processes just before Christmas. I tried to talk them into putting all the documents into one library, with customised fields, but they didn’t want it.

Revisions

People like and use the revision functionality.

Unfortunately, many people still persist in renaming major drafts and moving the old one to a sub-directory in the library.

We have been caught out a couple of times on this, because revisions are tied to the document name, and the document name is tied to the location.  As soon as you change the document name, you lose the revision history.

This one is a matter of training.

Document workspaces created through the document

SharePoint allows you to create a workspace for a specific document. You can work on the document in the workspace, add all your reference material and notes there, and when you have finished check it back into the parent library.  A fantastic tool, but we don’t use it.

Our document libraries are heavily customised—fields, names, etc. To date, I have not been able to create a sub-document workspace from anything except a standard ‘Document%20Library’ with no customised fields.

Some of our project users would love this functionality.

Check in/check out

This is another training issue.  If we don’t train people to use it, they won’t, and even then they’re unhappy about it.

Users expect write protection to work like MS Office.  When you open an Office document from a shared drive it tells you if someone else has that document open, and asks if you simply want to read it, or be notified when they have finished.

SharePoint doesn’t do this.  If two of you open a non-checked out document and update it at the same time, one person will overwrite the other one’s changes.  (Excel does say there is a mismatch.)

Email integration

Outlook rules at our office.  I would say it is the single critical piece of software people in our workplace must have.

Nobody, but nobody, uses any email/email functionality in SharePoint with the exception of:

• Two regular meeting workspaces I set up for monthly meetings
• Email alerts on issue lists.

Discussion boards

Discussion boards are an abysmal failure.

We have tried to wean users away from email on to discussion boards for technical and project discussions.  It has not worked.

I don’t really know why, but some of the reasons may be:

• Email is more immediate and less formal
• It is also more private, or appears so, anyway, even when you are (accidentally or otherwise) emailing the whole company
• We don’t have enough people. Discussion boards seem to need a critical mass to work
• Old habits die hard/resistance to change.

I would be interested to know what percentage of discussion boards overall, even outside SharePoint, succeed.

Form libraries

One potential killer application for SharePoint, in my opinion, is forms.

Our company chose not to implement InfoPath, so we do not use form libraries at all.

Such a pity.

Web part add-ins

There is no budget for SharePoint outside of the product itself.  If there was I would implement, in this order (and remember I’m talking 2003 here, not 2007):

• InfoPath
• A workflow (e.g. Nintex) 
• Rollups (e.g. CorasWorks)
• Wiki (e.g. Neoworks)
• SharePoint 2007.

Some of the free web-parts we use regularly include:

• Carlos Segura Sanz’ Cseg rollup, and
• Microsoft’s Office web components (not sure if you would call this one an add-in or not, or even free).

Overall usage 

We use SharePoint Portal Server (SPS) for most thngs, but that was more because of the way we implemented it, and our early knowledge.  People also like things displayed on the page, rather than having to do the extra clicks to go in to the content.

If we had to do it all over again it I would put a lot more into WSS sites. End result would be 50-50 SPS/WSS.

In a recent blog about the Ugly in SharePoint 2007, Tom Johnson asked about RSS feeds in SharePoint, among other things, and I replied with a rather lengthy comment that said although I hadn’t used SharePoint 2007, what I seen so far, and my experience with SharePoint 2003 led me to believe that it wasn’t going to be much use to the average office worker.

But it got me thinking, so after that I went back and looked at the RSS feature again, and now I’m not sure I was right.

Especially after two workmates who looked at it with me—both fairly ambivalent about SharePoint to date—said they liked the default RSS option that came with the list.

They’re both spreadsheet people. Normally their first instinct with any list is to export it to a spreadsheet.

In this case, they saw the RSS feed simply as better way to display the list.  While here I am, still thinking about traditional RSS feeds—gathering information from one location to display elsewhere.

So I was wrong about RSS feeds.  It is my thinking that needs to turn a little to truly see the value of it. 

The really good thing about SharePoint 2007, though, is that thre is enough improved functionality to make someone ambivalent about SharePoint 2003 sit up and take notice.

That’s a great selling point.

In his article The Good, The Bad and the Ugly of SharePoint 2007 Development over at SharePoint Buzz.com, the author talks about the ‘ugly’ of SharePoint 2007 as being

1. Selling - I have had the hardest time selling Sharepoint to my company. The functionality it provides out of the box alone would save the company in support calls, millions of dollars in mismanaged folders and bring in some organization into the company…

2. Training … Sharepoint is something I strongly believe the company can benefit from. However … the company is not willing to fork out the thousands of dollars for the product let alone the hundreds of dollars and time that I would need to train myself properly for the Sharepoint environment …

The Good, The Bad and the Ugly of SharePoint 2007 Development, by SharePoint Buzz.com, posted 5 January 2007.

(The original article was based on a post called The good and bad of MOSS 2007 development, New Year, New Job, New Projects!, by Sezai Komur.)

SharePoint Buzz sounds as though his company has not implemented SharePoint yet, and he cannot convince them to do it, but let me tell you, for some companies it’s almost as bad even once SharePoint is implemented.

Let’s use my company as an example. Two years ago the then head of IT decided to buy SharePoint.  There was no consultation with the end users, it was just a done deal. Some money was made available for portal design, and one of the IT support staff was sent on a two-day course—but only because we insisted—to learn how to set it up, integrate active directory, and so on.

So the in-house designer and myself, as content manager, taught ourselves as we implemented it. There was no budget for training. 

There is still no budget for training.  Even now I still answer most of the enquiries about access and security because there is no budget to send the support team on training courses, and “They can’t afford the time out for internal training”.

As for end users—whenever I try to organise internal training for end users I get, “They don’t need to know”, or “The program isn’t important enough in their day-to-day work for us to take them away from their jobs”, and so on.

Most people go out of their way to resist change.  It’s human nature.  I don’t blame them for finding excuses not to use SharePoint.  They need to be sold on the product.

Selling SharePoint is the hard part.

I can sit down with individual users in the company, show them what a great product SharePoint is, and what you can do with it. They are often enthusiastic, but if we can’t implement something immediately that enthusiasm wanes.  Of course it does. Out of sight, out of mind.

Until I can sell it to the people who matter—the heads of department—the people who can issue a directive and say, “You will do it this way from now on”, SharePoint is never going to provide the benefits it should.

It’s a hard sell. These department managers were mostly here two years ago. They had SharePoint presented to them as a fait accompli. They didn’t want it. They didn’t see any need for it.

We, the people who implemented it, didn’t know enough about it in those first vital months to sell it to the people who mattered.

We’re slowly getting people onto SharePoint, but it’s a hard slog. Much harder than it should be. 

Obviously, with the experience we have now, we would do a better job of selling the product in those important few months, and we would have concentrated on the people who really needed to be sold to.  But without that training, without that experience, we did it the hard way, and we have a lot of ground to catch up.

So SharePoint Buzz, I say you have captured the two ‘ugly’ points about SharePoint really well. It’s a great product, and I mean SharePoint 2003 as well as 2007.

It is a hard sell, and it’s even harder to sell (not to mention implement), without training.

Today I had one of those ‘Eureka!’ moments where a whole lot of disconnected information suddenly fell into place. Good feeling.

As a self-taught SharePoint user, there are big gaps in my knowledge, and the worst thing is that much of the time I don’t know what I don’t know. 

I also dabble a bit more in the technical details than the average SharePoint end user, but I’m not a developer. I haven’t coded (as a job) in a very long time, so while I can understand the concepts I definitely couldn’t sit down and write web parts using .NET without a lot of upskilling.

I am moderately comfortable with Javascript, however.

I dip in and out of the Microsoft SharePoint sites. Each time I understand a little more. Today I decided to take another look at the Hello World Custom Menu Web Part.

This rather nifty little example shows you how to add a menu item to the Edit menu for documents in a document library.  The example they start with displays a “Hello World” dialog box, but then they go on to show how to use the same process to add a “send an email link”, which emails a link to the document you are currently looking at.

Cool.

So, how do they do it?

They add a content editor web part, put some Javascript into it, and then hide it. The Javascript adds the menu option to the document library, which is another web part on the same page.

That’s when I had the Eureka moment.

A content editor web part isn’t just for adding text. 

I have only ever used content editor web parts to add text up to now. Admittedly, I have embedded Javascript in that text sometimes, but the Javascript has always been specific to that particular web part. Simple little things like a date countdown displayed on the page, or mouseover functionality.

Now I suddenly realised that the Javascript I add to that content editor web part can be used to affect other parts of the page. And I remembered, then, an experiment I tried with inline styles early on in my SharePoint life. An experiment I stopped abruptly because the styles in that particular web part impacted the rest of the page. I didn’t understand why at the time, and didn’t follow it through. Now I understand. It’s not just Javascript that I can use. It’s any content (within reason) that can be added to a web page.

It’s so simple. So obvious. Now it’s starting to make sense.

Today I was reminded that no matter how professional you may believe you are, no matter how experienced you are, you must never, ever forget your audience.

It was the end of a project. The project files were stored in SharePoint, but in the portal server, rather than on a separate project site. (We set the project up in the early days, when we had no real idea of what we were doing.)

We planned to back down the database to store with the project, but we also decided to copy the really important document libraries down as individual files, and store them with the other project documentation. This was probably overkill, but this is an important project and a couple of extra storage discs was worth the peace of mind.

I don’t know if you have ever tried to restore SharePoint documents from the tables, but they are huge—and for some reason files of the same type in a directory restore to the same size. You can sometimes open a file, save it, and the file size reduces dramatically, so there is some sort of overhead in either the way the files are stored or in the way I download them.

However, I digress. That’s not what this blog is about.

Downloading to the network was slow. It took four to five minutes minimum to save each file. It would take forever. So I downloaded the files to my PC’s c: drive, planning to copy them across to the network later.

The download worked fine, but when I tried to copy the files across to the server I hit the same problem. Each file still took four to five minutes to copy.

So instead I decided to let people access the files from my c: drive. Our developers do it all the time, hopping on to each others machines to check out code.

I made the directory readable, and sent an email to the project managers telling them that I had put the files onto my c: drive, and gave them the name of the PC.

I forgot one thing.

These people were not developers.

They’re like most people. They expect local drives to be just that, local to the PC and inaccessible to everyone else. I gave them my PC number and expected them to know what to do.

I had forgotten my audience.

I had some other work to download for the project. Small stuff, and I had other priorities to complete first. When the project managers asked how I was going, I assumed they meant the small stuff. (Second mistake. Never assume; always make sure you are both talking about the same thing.)

It was a week before I realised what the problem was.

Two weeks out from the end of a project it was precious time to lose.

And all because I assumed my audience knew something they couldn’t possibly have known.

SharePoint can be a marvellous project management tool—provided you let it.

In order to do this, however, you have to think about how it can benefit you, and change your processes accordingly.

Sadly, until SharePoint is well established, most people won’t do this.

Take a really simple example.

A company I know uses SharePoint Portal Server as their company intranet. On the intranet they have a social area.

Every year this company holds a children’s Christmas party. Staff members bring their children along to the party where they eat party pies, play games and meet Santa. Each child gets a present from Santa, based on their age and gender.

The social page on the intranet advertises this party. It tells when the party is on, where it will be held, and what to do if you want to bring your child along.

The company needs to know the following:

• Name of each child
• Age of each child
• Gender of each child.

How do they do it?

They send around an email with voting buttons.  Yes, I am bringing one or more children; no, I am not.

They ask you to include in the reply, the name, age and gender of each child.

A member of the social club receives the replies. They transfer the names to a spreadsheet.  They use this spreadsheet to plan catering, and to work out how many presents to buy for each age group.  They also use it to print labels for each present.

This is prone to error.

• Emails get lost in the many work emails that come through
• The parent replying may add their child’s name, but forget their age or gender
• The social club member may be in a hurry one day, and forget to transfer the name(s) to the spreadsheet
• They may mis-type the name when transferring it to the spreadsheet. Ditto the age, and gender.

It takes time. Time to set up the voting email, time to transfer the detail to the spreadshet.

So, how might we do this better in SharePoint? Remember that a page already esists advertising this event.

• Create a custom list with three columns—child’s name, age and gender. All of these fields would be compulsory.
• Create a view that only displays items you (the person viewing the screen) have added
• Add the list to the page, using the new view you have created

This is a simple list. It will take at most five or ten minutes more to set up than the voting buttons would have.

Now, copy the address (URL) of the page. Write your email exactly as you have before, but instead of asking the people to reply to your email, ask them to click on the link to the page.

Each parent goes to that page, and adds their child(ren)’s information by clicking Add New Item, and adding an item for each child. 

They can’t omit any of the information because each field is compulsory. Not only that, because the view displayed on the page only shows the children they have added, they can see immediately whether they have made a typo and fix it.

Each parent has had to do maybe two clicks more than they might have done otherwise, but that’s all.

What about the social club person?  Yes, so far they have spent five or ten minutes more creating the list, but that’s it.  And now the usefulness of SharePoint comes to the fore.

They don’t have to receive the emails. They don’t have to transpose the names to a list. It’s all done for them. Not only that, we have eliminated nearly all potential for errors.

All the social club organiser has to do is export the list to a spreadsheet when they are ready to print labels and organise catering.

They have saved themselves 90% of the work. (Not 90% of work organising the party, but 90% of the work gathering the names.) And the results will be accurate.

Unfortunately, the company mentioned is not SharePoint savvy yet. When this idea was suggested, the reply was, “But it’s too hard to set up.”

You counter with, “Yes, it may take an extra five minutes to set up, but think of the time and effort you will save later.”

They came back with, “But it’s confusing for the user. And anyway, it’s not that much effort to transfer the names from the email to the spreadsheet.”

Nothing you can say or do will make them budge.

They won’t make the mind shift.