Sharepoint

Last week I took a class at Panurgy on Sharepoint Server, because we've started using it at work, and I've done a bit of development on it and found it interesting and enjoyable. Unfortunately, when I signed up for this class back in October, it would have been just what I needed, but then it got rescheduled, then cancelled, then rescheduled. By the time I got to it, the material it covered is all stuff I had already had to figure out on my own, the slow way, by trial and error. I learned a few things in the class, but mostly, I was breezing through it, and in a lot of cases teaching things to the other student (there was only one) and even to the teacher. I'm signing up for a full-week class next week that should cover a lot more of what I want (alongside a lot of things I probably can't use, at least not on the server at work, since I am not an actual administrator of that server).

The hardest point for learning Sharepoint for me is getting the answer to the question "What is Sharepoint? What does it do?" to crystallize. The answers to this question are usually mired in lots of very broad, very vague ideas, that must mean a lot to people who already know about this stuff, but not as much to me. For instance, Wikipedia's article about it starts (as of this writing), "Microsoft SharePoint is a family of software products developed by Microsoft for collaboration, file sharing and web publishing." For me, that's not very helpful, because when I first started with Sharepoint, it didn't tell me how it was different from, say, a server with FTP and Apache on it. At the other extreme, I would get mired in too much detail about specific things like workflows, document versioning, or the laundry list of functions you can add to a site (wiki, blog, forum, calendar, etc.). It felt like a big grab bag of everything, but with no particular purpose, and I kept thinking, "Why would I want to use it?" After all, if I wanted a wiki, or a blog, or a calendar, I have lots of easier ways to get those things.

The project that made me actually start using Sharepoint was a help desk system. We were pushed by an auditor's recommendation to setting up for my section a system that tracked the status of all the requests made of us, and since we had to do that, I wanted to make it useful for us too, by serving as a record we could turn to when trying to solve a problem to see what had already been done in the past. We've always had a big shortfall in our uniformity of documenting these things, and our ability to cover for one another. It turns out Sharepoint has a help desk system available right out of the box, and the statewide IT people have a Sharepoint server already up, so we just had to buy a few client licenses -- which we can use for any Sharepoint application, not just this one -- and we've already got a help desk, with trouble ticket tracking and history, a FAQ, and a knowledge base.

And it really is a pretty good help desk, but we found the need for a number of customizations. Fortunately, most of these were quite easy -- or would have been, if I'd been able to take this class a few months ago. Finding them was quite tricky with no help, since there was no documentation at all about the actual help desk template, and precious little about Sharepoint (and most of that bogged down in details of how to configure the server itself, or limited to how to use the predefined calendars and wikis and stuff). But once I learned the basics of navigation and how to make customizations, most of them were incredibly easy. Need to add a new field to a list? It's just a few clicks, and then no need to go back and edit reports or views or queries to accomodate it, that's already done for you. Making new lists is pretty much just as easy. Even customizing the layout of pages themselves is quite simple, though some of the things you add are a bit more complex.

I was able to get the site to a usable state and we've been using it within my section for more than a month, and as of this writing, we're just starting to let users get into it to enter and view their own requests. It's working pretty well so far, and we're starting to build up a knowledge base that is consolidating our scattered notes about how to do things better than we've ever managed before.

Even so I'm running into limits in my ability to make it do things that seem like they should be simple. For instance, every service request is associated with one or more devices. The idea is, we want to be able to see the history of past requests associated with a device, so when a new one comes up, we can tell what has been done in the past, or identify repeated problems. But it's proven surprisingly difficult to do this efficiently. I could easily make a view to do it, but then I'd need hundreds of views, one for each device (and user, and agency). We can do a search on the text, but it occurs in too many places. I think this is probably solvable and I have some ideas, after the class, for ways to solve it, but this is where I'm reaching the limits of my knowledge.

And it'll be far more so when we start talking about using Sharepoint for other projects. And it would be even more so yet if I ever wanted to use Sharepoint in any other capacity than at my present job (for instance, one job I applied for last year, I didn't get, perhaps in part due to a shortage of Sharepoint knowledge). Sharepoint seems like one possible place where I can update my tech skills because I can actually put what I learn to use, and that is the only way I am able to retain it. So I'm excited at the prospect of taking that next class and finally getting to really learn more.