That said, there’s nothing more annoying than having to sit there with those little popup windows in the bottom of the Facebook UI while trying to hold a conversation… enter, the jack-of-all-trades chat application, Pidgin. Using the XMPP protocol option in Pidgin you can map your Facebook user account to the IM client, allowing you to chat with any of your Facebook friends outside of the Facebook UI. Simply add a new account, and set the following fields.

I have left my job as a SharePoint developer for a certain large defense contractor, and have moved to sunny (and HOT) North Carolina for a SharePoint Consulting job with Intellinet. I’m really excited to be starting this next leg of my career with Intellinet, and it’s an opportunity that should make much better use of my skills and enable some travel (and you all know I’m always up for that). Consulting was always where I wanted to be-in my opinion the ideal mix of people, technology, business processes, and project diversity. I’m only mildly excited, I’m sure you haven’t picked up on that!

Once I get a bit more settled in I’m positive I’ll be back at the blog, so hang in there, there’s still more to come.

Richard Tweet

One of the things that a lot of SharePoint implementations lack is a true understanding of how the front end of the SharePoint intranet/portal is going to interact not only with the various backend systems you’re trying to bring together, but almost more importantly with the business process itself. Sure it’s great to put the latest and greatest technologies in front of your end users, but until you truly understand how the end users are going to be interacting with the environment it’s virtually impossible to develop an effective, usable intranet.

When it comes to SharePoint, this is (in my opinion) where we see the biggest level of change; the shift in methodology in how we think about what we’re developing. We’re not “destroying” intranet design, but rather turning it on its end; looking at it from the point of view of the end users. Five years ago we’d be focused on where all of the data is and how to bring that data together, leveraging the power of technology. Today that power extends far beyond the bounds of simply displaying data, offering an environment rich in collaboration (let’s not just show the user some data, let’s let them interact with it). How does Joe Bag-of-donuts interact with this, how do we trim the waste out of the process he’s following, and how do we streamline the communication and flow of data from the publisher to the end user (let’s not forget the power of lean thinking, especially when you’re trying to justify the cost of your proposed shiny new portal to the bean counters).

In your traditional intranet environment that “publisher” is historically a few defined groups, maybe the communications department for example. In the SharePoint powered intranet world, Joe Bag-of-donuts himself can easily author content (still requiring authorization by the communications group before publishing), or create a rich dashboard to share with his specific team or work center. It’s this fundamental shift of looking at things from this “new” perspective, and actually empowering the end user to make decisions that’s ultimately redefining how you develop for the corporate intranet.

Why do we put ourselves through this pain?

Solid documentation is really the key to success of any major system or platform. You may be the one to build it, you may be the one to manage it, but sooner or later those keys change hands, databases go offline, patching doesn’t go according to plan, Joe Bag-of-donuts “tweaks” some code and breaks it, you name it… things happen. And it’s the documentation to the rescue (especially if the original architect, developer, or analyst isn’t around). Solid documentation can also help the customer to become more self-sufficient and less reliant on the original development and integration team; though anyone in business will tell you that 90% of the time the first question is “who built this originally?!?”

What should this look like?

Many people have their own approach to documentation. Some like to create one massive document, while others (myself included) tend to break them apart into smaller more manageable volumes that group related information together. The volume based approach also means that you can separate raw technical data (such as the disaster recovery procedure) from the more day-to-day information written for the eyes of the administrators or end users.

There’s not necessarily a right or wrong way, but there’s certainly extremes that in my opinion should be avoided. If you’re presenting the customer with a 200 page document, then you probably could have made it a little more pleasant for them by breaking it apart.

What do I need to document?

A solid set of documentation should include a complete disaster recovery plan, and an administrative guide for your “administrative” users. Depending on the scope of the project or the requirements you have been given it’s also sometimes times necessary to provide end-user training material. The way I tend to structure things is to start with your base Disaster Recovery (DR) procedure. This should walk through the recovery of the system both from the perspective that you’ve lost absolutely everything and have to start over from bare metal, and the perspective that you’re recovering from a backup. As you build your DR procedure, identify the steps that can stand alone as their own procedure, split those into their own document and reference that new document within the DR procedure. This allows for easier reuse of the material in the future. When you want to tell someone to install a feature as an example, you can point them to document “017 – Feature Installation” as opposed to sending them to one massive document that they have to search through looking for the section on feature installation. Use this same approach with your administrative documentation. Is it really necessary for someone to have to skim through the sections on custom CSS styles if they’re looking for information on the system’s permission model?

How detailed do I have to be?

The general rule of thumb is that someone should be able to walk in off the street (with the right qualifications and skill set), pick up the documentation and be able to perform the tasks described in the documentation. When we’re talking about disaster recovery as an example, any member of your server team should be able to completely rebuild your environment by following your DR plan. Assume “disaster”, so assume the original team isn’t there; that environment has to be restored (sometimes from bare metal) using nothing but the documentation.

Also think about the day-to-day use of the platform. An administrative guide as an example should cover all of the tasks that the SharePoint administrator performs. You don’t always have the luxury of a turn-over period to train a replacement; what happens if you get hit by a bus tomorrow? Is there someone else on the team that’s intimate with the permission model, the various customizations to the UI, the integration with the business process (and those critical paths of information flow and process)? It’s always important to remember that just because your mind works a certain way doesn’t mean that the next person to come along will think the same way.

When do I create all of this?

This depends entirely on your personality. Some people wait until the very end then try to scramble through it (this often results in incomplete documentation). The best practice for this is to create things like your DR procedure while you’re building your development environment. You then can test the procedure by building your production environment from the documentation. If staffing permits, it’s not a bad idea to have someone other than yourself or the original server admin perform the OS configuration and SharePoint install/configuration. This gives you a good litmus test of potential holes or areas of interpretation that you should clear up (remember, you have to assume you won’t be there in the event of a disaster).

How do I know if all of this works?

Any good set of documentation will have a test plan associated with it; a set of procedures that the server team and administrative team can use to test the functionality of the system. Test plans allow you to ensure that the same sequence of events is followed every time, ensuring the same outcome and allowing you to detect anomalies. While the steps in a test plan will become routine and second nature over time, it’s important to continue to follow them (much like a pilot going through his pre-landing checklist). Test plans are most useful during the User Acceptance Phase of a project and to confirm that a system performs normally after patching or some other maintenance event. You can often use a test plan to tie back to your other documentation volumes. As an example, a test procedure may require you to install feature XYZ via the system’s feature installation procedure. This will result in that procedure being tested and proven prior to a system’s go-live event.

It’s also important to test a system’s disaster recovery procedure. In a lot of cases, DR procedures don’t get tested until something (disasterish) happens, then you find out that there are holes in it, or the data wasn’t being backed up the way it was planned, or the data simply didn’t restore as planned. Prior to a system’s go-live event it’s critical that you put that disaster recovery procedure to the test. If you’re in the service delivery business, you probably have a service level agreement (SLA) with your customer that specifies how much time you have to perform a restore from backup. If you haven’t tested your procedure chances are the times in your SLA aren’t accurate (something that can potentially burn you down the road). When in doubt test the procedures. If nothing else you’ll gain valuable experience and capture more objective evidence on the structure and performance of the system.

I attended some great sessions by Mark Anderson (@sympmarc), Christina Wheeler (@cwheeler76), Fabian Williams (@fabianwilliams) and Mike Oryszak (@next_connect), was finally able to put real life faces to the folks behind those avatars that oh-so-often show up in my Twitter feed, and meet loads of new people that now seem to be popping up in that same feed. This being my first SharePoint Saturday, I’m still taking it in to a certain extent. These events are a great place to share technical knowledge, learn practical skills to take back to your day-to-day work, and network with new people in this exciting field (that might have sounded a lot like a canned marketing line, but it’s true).

It may have been the sheer scope and record attendance of SPSDC that lead to such a mixed bag of sessions, but there was truly something for everyone. Some of the sessions were very technical, while others were more process oriented, and as with the sessions, I found the attendees to be quite a mix too. I spoke to people that were IT Pros and top shelf consultants, and I spoke to people that were brand new to SharePoint and didn’t really know much of anything. The only problem I had was picking which sessions to attend since there were so many going on at once. This clearly could have been a two-day event, though that would have defeated the “SharePoint Saturday” name wouldn’t it.

The last point I’ll make is the importance of Twitter. All of these people use Twitter (after all, we are in the business of collaboration) and it was Twitter that ultimately brought me to SPSDC. Twitter even brought me to people after I got to SPSDC; at one point I was browsing the #SPSDC hash tag and discovered that Janis Hall (@janishall) was in the same room, sitting behind me. If you’re a SharePoint person, you really can’t afford to not follow the people linked in this post! All in all, a great weekend with even greater people; now I just have to decide which event to attend next, though I’m starting to lean towards SPS Chicago at the end of July; we’ll have to see how the schedule pans out.

If you’re one of those organizations with a really rigid change management process you may be happy to learn that it’s incredibly simple to add some event logging to your feature installer to record that activity in the Windows Event Viewer. This has a few prerequisites, like having admin access to the box in order to write to the event log; but if you’re the sysadmin of the environment that shouldn’t be an issue. You can always opt to install your features as the resource pool account also, which may or may not mitigate that issue depending on your environment.

Here’s a little example installation script with some logging:

echo off
SET STSADM= "c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe"
SET /p WSPPKG=Enter Feature/Package Name (without .wsp / must be stored in c:\):
SET /p SVRURL=Enter Deployment URL:
Echo Adding Solution
%STSADM% -o addsolution -filename c:\%WSPPKG%.wsp

Echo Deploying Solution
%STSADM% -o deploysolution -name %WSPPKG%.wsp -local -allowGacDeployment

Echo Installing Feature
%STSADM% -o installfeature -name %WSPPKG% -force
EVENTCREATE /L System /T Success /SO "SharePoint" /ID 3 /D "%WSPPKG% Installed"

Echo Activating Feature
%STSADM% -o activatefeature -name %WSPPKG% -url %SVRURL%
EVENTCREATE /L System /T Success /SO "SharePoint" /ID 4 /D "%WSPPKG% Activated"

Echo INSTALLATION COMPLETE

There’s a few different methods to using Embed Tweet. If you’re using WordPress there’s a plugin available, or you can manually include the code. Embed Tweet allows you to load the Javascript right from their server, although I went ahead and copied the code right into my site so I could make some minor tweaks to it. Embed Tweet works by finding links to individual tweets throughout the site or page where the Javascript is deployed. Obviously it would wreak havoc on my “recent tweets” widget on the right, so I went ahead and set the “automaticEmbedding” value to false. This tells the script to only embed tweets if a link has a class of “EmbedTweet”.

Once you’ve included the necessary Javascript, all you have to do is make a link directly to the tweet with the “EmbedTweet” class, and your link will be replaced with the tweet itself. It’s not necessary to specify text for the link, as the link will be replaced anyway, though I always do just to keep track of where the tweets are in my post and which one it is.

As an example:

<a href="http://twitter.com/sympmarc/status/13459046853" class="EmbedTweet">Tweet; Marc Anderson</a>

Tweet; Marc Anderson

Pretty slick, eh?