Having grown up with instant messaging as an integral part of communication (yes, I’m of that generation that would rather IM, Text or E-Mail than actually use a phone to make a call) I’ve obviously noticed that pretty much nobody uses AIM and those other chat protocols that we all grew up with. Just for kicks I logged into my AIM account to find maybe 3 people on my buddy list actually online. While protocols like Skype have made a dent in the market, having cracked the voice and video chat world, the big player now is actually none other than our illustrious Facebook. Continuing that trend of rooting itself in absolutely everything anyone does, pretty much everyone has a Facebook account, making it the ideal medium to keep in touch.

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 felt that I should post a little update of what’s been going on, after all I’ve been missing from the blog scene so long it almost feels like I’m starting over. Much has happened since my last blog post, including (it seems) two upgrades for Wordpress that I’m going to need to get on.

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.

There was an interesting Tweet earlier from Richard Harbridge regarding the effect of SharePoint on intranet design. The article pointed out several interesting points regarding the complexity of developing on an intranet optimized platform. But while the platform itself has certainly been optimized to support the scope and scale of intranets (both large and small) the platform itself really needs to be tailored to meet the specific needs of the business.

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.

In this installment I share with you a talk from Clay Shirky on “how social media can make history”. Shirky discusses the effects of social media on society, the radical shift from other mediums to those of social media, and the increased transparency and connectivity of information that stems from social media.

You may have seen my complaint via Twitter about how I’ve been working on nothing but documentation for the last couple weeks (a task many of us technical folks consider to be the bane of our existence). I claimed that because of the documentation I had nothing cool or exciting to blog about, but then it was suggested by several folks that I blog about “the documentation”. The more I thought about it, the more I realized that many of you (be it new to the SharePoint world, or just simply less experienced) may not have had much exposure to this, so an overview is a pretty good idea.

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.