about a CMS that can drive a content manager crazy. Case in point – I spent close to four hours today creating 30 or 40 essentially identical pages. Leaving aside the pointlessness of needing that many pages on a single site, it’s probably not the most efficient use of time. In the old days, working in plain HTML, I would simply copy and paste the text into a new file, make what changes I needed, and away we go. Given what little I changed, I expect the whole business would’ve been done in half the time.
Instead I had to go in and add multiple webparts multiple times, and set the custom properties of each, publish the pages, and then for some reason I couldn’t use the built-in move features and I had to Windows Explore to get all the pages where I wanted them. I’m quite certain there are ways to copy pages in Sharepoint; our tech folks were working on something but didn’t have enough time to get it all worked out for me so I did it all manually. What I think it underlines is that Sharepoint is a complex tool, and it creates pages out of a lot of separate moving parts rather than a single lump of code.
So does this make Sharepoint a bad tool? In some ways I think it does. Simple things need to be simple if they’re going to work well for users and content managers. Again, I know there are ways to do this, and given enough time and resources we’ll find it and all will be well. But it does raise the issue of complexity and its pitfalls (See Paul’s post on the subject for more). There are many reasons to be able to do more things simultaneously; also many reasons to be able to do things in multiple places at once. The complexity of databases that run Sharepoint and other DB-driven applications is a totally different paradigm, however, and it can overwhelm a content manager who just wants to get his work done.
On the flip side, if you can get the pieces in place and functioning properly you can do some tremendously powerful things. I think the trick of it all lies in two things. 1) If you possibly can, get everything in place before your entire site goes live. I don’t mean that one can thing of everything, only that if you can do an incremental rollout and make sure silly things like this are covered before a section or an app goes live, do so. The more likely scenario is 2) accept that the first year or so after go-live will be a period of alternating frustration and elation. A team’s entire work process will be impacted by these kinds of surprises, and this first year becomes a sometimes clumsy shakedown exercise.
0 Responses to “It’s the little things”