I thought it was a joke. Who could blame me? After all, the announcement began: “Starting on April 1, 2009…” Then again, Microsoft usually ain’t one to make “April Fool’s” jokes.
I read the announcement again. I clicked the buttons. The download started. I double-checked the URL — “Perhaps it was a fancy phishing scheme,” I thought to myself. “Better check.” “Free” often means free trouble.
I Googled. I got half-a-dozen links. I clicked the Wikipedia entry. It said: “SharePoint Designer 2007 is available as license-restricted freeware.”
Hey, if Wikipedia says so, it’s got to be true, right?
Here’s the scoop, the lowdown, the straight poop:
As of April 1, SharePoint Designer is free. Get it here. Now, it’s not free as in speech, but it is free as in beer. Shamelessly, let me admit here and now. I use SharePoint Designer (hereafter referred to by me as SPD). I use it almost every day. It lets me work magic. It’s a buggy piece of ssssssss…software, but it lets you do magic.
Since we’re talking beer, I liken SPD to Mickey’s Big Mouth Ale — AKA the “green grenade.” It’s kind of rough, kind of wild. But, like SPD, I also like Mickey’s — at least I did when I last drank beer. Perhaps there’s still a bit o’ cowboy in me.
Nevertheless, it’s one of those things I’m not sure I want to advertise — liking Mickey’s, SPD, or the cowboy part. None of them are things you’d mention in the mixed company of a crowd of open source, micro-brew city-folk.
But, it’s true — acceptance is the first step — I like SPD — that affection affliction goes hand in hand with my liking SharePoint. Don’t tell anyone. SharePoint rocks.
Like it or not, to work SharePoint, to do real SharePoint magic, you need SPD. It ain’t a luxury, it’s a necessity. Moreover, you don’t want to touch SharePoint with FrontPage. You don’t even want FrontPage to flirt casually with IIS when it’s hosting SharePoint. You don’t even want it to sidle up and try to buy it drinks, casual-like.
FrontPage will break SharePoint quicker than you can say “Joomla.”
On the other hand, with SPD, a little bit of undaunted adventurism, and some cowboyish bonhomie, you can work magic — good magic as well as some of the sinister dark arts, things like custom workflows, fancy dataviews, and point-and-click connections to XML webservices. Welcome to the dark side.
In fact, it’s SPD that will let you turn that all-too-boring look of SharePoint into something almost purty. It’s all there, it’s all in SPD, and now it’s free.
Let me warn you though. Like that green grenade, SPD is big, and brash, and none too gentle in its approach. You know what they say about “operating heavy machinery.” SPD does not have a light touch. The fact of the matter is, SPD can wreak havoc — breaking a MOSS or WSS site in two shakes of a lamb’s tail. Moreover, it’s prone to crash — especially when messing about with the dark arts of dataviews.
I’ve learned. One must use the “undo” button judiciously. Moreover, it’s wise to only create (and destroy) web parts in a temporary environment; you should, at the very least, isolate your cowboy antics to a subsite for god’s sake, if not a stand-alone development environment.
[On the other hand, that’s the nice thing about webparts — do ‘em right and once you get them done and all nice and shiny-like, just the way you want ‘em, they’re easy to move about. Importing (and exporting) is easy. I typically develop my parts on a stand-alone WSS site, and then import them into MOSS when they are acting proper. Sure, this is just good sense, but the portable nature of web parts makes this pretty easy too. ]
The Dark Arts: Custom Workflows
One of the extras you get with SPD is custom workflows. SharePoint OOTB workflows suck. Custom workflows are magic — black magic, pure and simple — and they are, to me, an example that the IT industry has finally managed to somewhat lessen the gap between the marketeer’s hype and the reality of real-life computing. Perhaps we are finally seeing the age of integrated software that actually interoperates, does what it says it does, and makes your teeth whiter, your hair thicker and more luxurious.
Back to the magic: workflows are magic. Incredibly, with SPD, custom workflows are at your fingertips for no extra costs; a standard feature in both MOSS and WSS. All it takes is SharePoint Designer. Sure, it’s not K2 — then K2 is slightly more expensive.
Here’s a simple example:
We scan lots of documents. We use a fancy scanner. It connects to an automated, server-based PDF conversion and fancy OCR system. It not only scans and converts the docs to PDFs, it also automatically tags them with custom metadata before sliding them smartly into a SharePoint document library. It tags them using information the OCR system pulls from a custom coversheet. It works. It’s great, except for some persnickety problems with people’s names.
For reasons only known to the gods of OCR, some particular names never seem to make it through the OCR process intact. Moreover, they are predictably wrong. I won’t say the original names, but my two favorite OCR errors end up as: PASSMOKE and SLANDER. And, while that might make a terrific name for a law firm, I wanted zero defects.
My solution, on the other hand, was rather simple. I used a simple SharePoint workflow. With a workflow it was easy to fix. In fact, my first cut was done in less than 5 minutes.
In a nutshell, I created a workflow that examined all new documents, looked at the metadata for the known OCR errors, and, in the wink of an eye, corrected them. No muss, no fuss, no kitchen drudgery. It only took two steps. Here’s how:
Using SPD, attach to the proper site and create a new workflow. You find it under File/New/Workflow.
You see a screen like this. This is the toughest part. You’ve got to name it. While you’re here, you choose if you want it to start automatically and/or if you want it so you can start it manually. All this can be changed later, so — while debugging — I choose “manual.” Once it’s all smooth sailing, I switch it over to automatic.
Here, you also choose what list or document library or other SharePoint item you want to attach the workflow to. This is the downside of workflows, by the way. They have to be attached to a SharePoint item and once attached, they’re stuck there. This means that you absolutely have to develop the thing in a production environment. Steel your nerves and quaff that grenade.
Once you’ve named it and attached it to a SharePoint item, you get presented with a set of screens that allow you to build your workflow steps based upon various conditions and variables. The nice thing — starting off — it’s all point and click.
In this example, I use a set of simple IF/THEN conditions. Basically:
o IF [STAFF] equals “SLANDER”
o THEN set [STAFF] to “Correct Name”
Since the universe of errors is relatively small, it could work to simply hardcode the various cases, one after another. That’s it in a nutshell.
Now, in reality, I got fancier. Not wanting to hard-code a series of problematic names forever, I instead decided to use an existing table of staff names — treating it as a lookup table.
SharePoint workflows can perform limited lookups, matching information in one list to fields in another. It can then, based upon that match, substitute one value for another.
In this example, the workflow fixes my SLANDER problem by checking a list of possible errors stored in one list, finding the proper name based on that match, and then slips it into the original field, correcting the error.
It takes a bit of puzzling to get the logic straight — and if you ask me, all the help text just adds to the confusion. In the end, I found that just clicking the options — in a logical order — worked. Like most Microsoft products anymore, over-thinking can get you in trouble. Just push the buttons.