Skip to content


Article: A Sensible Framework for SharePoint Intranet Navigation

It’s never the first thing that I get asked on an engagement. It’s never the burning question in the minds of my customer as they seek out a consultant to help them with SharePoint. However, sooner or later it eventually comes to the topic of navigation. Although the fundamental concepts behind a sensible navigation framework are simple, they are not well understood by developers or designers. This article is designed for both audiences as they seek to make SharePoint usable.

Foolish Consistency is the Hobgoblin of Little Minds

Emerson (who said “Foolish consistency is the hobgoblin of little minds”) is a personal favorite author of mine;
however, he didn’t have to train hoards of users how to use a new interface. There’s definitely something to be
said for creating the kind of navigation that users are accustomed to. In the world of the Web that means
navigation belongs on the top and on the left.

Nearly every non-marketing Web site will follow a pattern with navigation on the top and on the left-hand side.
While what is on the top and left side differs, the fact that these spaces are reserved for navigation normally does
not. So if you’ve got a wild side, or feel like training scores of users, you can move the navigation — otherwise
we’re more or less stuck with the accepted norm.

Please enjoy a free copy of this article, also located on our Gifts page

Article: Caught Up in Code, or Quick Configuration

Many new programs are starting to blur the lines between something that should be enforced through specific flow control in code and when it’s the right decision to allow some decisions to be made by the configuration of the software. Here, you’ll explore that line and how it impacts your development.

Code is Well Known

Most developers and architects default to creating solutions for their problems directly in code. They put an “if…then” statement in the code and call it business logic. For example, if there is a specific property available, then the application must show an additional link. If the property shows that the user is a member of a certain group, then an additional menu may need to be displayed.

Situations like these arise every day. Creating a simple “if…then” statement is the obvious solution to the problem. But is the obvious solution always the right one?

Configuration Is Quick

Configuration, rather than a quick “if…then”, maybe the answer. Configuration is focused on creating ways to simplify individual business logic into a set of values that can be stored as configuration rather than hard coded into the logic of the program. Configuration is converting hard-coded logic into data that the program can operate on.


Troubleshooting Web Parts and Deployment

This isn’t the article that I set out to write. While researching another article (coming soon) I soon realized there just isn’t a lot of good material on how to troubleshoot Web part deployment, or even precisely how Web part deployment via STSADM even works. This article is designed to explain the moving parts of the deployment process and describe what can go wrong. Hopefully, it will help a few people get their implementations up and running more smoothly.

Why Deploy with STSADM?
Before getting too deeply involved in fixing STSADM Web part deployments, it’s important to understand what STSADM is and why it’s a good platform for troubleshooting Web part deployment.

STSADM is a ‘utility knife’ type of tool that ships as a part of Windows SharePoint Services. It does a wide range of things from site creation to Web part pack installation. If you have SharePoint Services, you already have this utility; it is typically found in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Bin.

Article: Five questions to ask before buying a new tool

Before buying a tool, make sure that you understand the problem, all of the alternative solutions to the problem, what else you’ll need to implement the solution, and whether it’s a problem you should even try to solve on your own. Developing a routine before buying tools will help to prevent purchasing tools that you’ll never use.

My father is a tool guy. He has more tools than any sane person should have. I learned that there are a dozen different saws—each for a different purpose. I’ve inherited this love for tools, although I get more crazy about gadgets than power tools. I realize that I’m not alone. Often times I recognize an automatic instinct in clients towards buying a software package to solve a problem — and occasionally even a hardware purchase. Unfortunately, the tool—whatever it is—is just a tool. It can’t solve the problem by itself. It needs to be wrapped in a solution to solve any problem. Here are five questions to ask before you buy a tool to try to solve a problem.

Do you understand the problem?

Most of the time IT professionals are so pressed for time that they don’t make sure that they fully understand a problem before they try to solve it. We talk about requirements for big projects but we often forget that the same principles apply to smaller purchases.

For instance, a recent client was confronted with a group that needed Act!. Of course, that was a solution, not the problem. The problem was a basic contact management problem. They needed to keep basic details of contacts for a group of people. The client already had Exchange — but ended up purchasing Act! because the requirements weren’t understood. The group that Act! was purchased for is slowly moving back to an Outlook and Exchange public folder solution. (To be clear, there are some problems for which Act! is the right solution — it just wasn’t a good fit for this organization.)

When you do and don’t want Shelfware

No matter the size of your organization, you can be sure you have old software sitting on a shelf somewhere. Robert Bogue talks about how to reduce the shelfware in your company.

Every organization has “shelfware” (software that has been put on a shelf). Whether an organization has 100,000 people or only one person, you can be sure there’s software sitting on a shelf somewhere in the building. In some ways, shelfware is like cholesterol. There’s a good kind of shelfware and a bad kind of shelfware. The trick is to increase the good shelfware and reduce the bad shelfware.

How does shelfware become shelfware?

There are actually a few different kinds of shelfware, some shelfware was never used or never returned the value that was intended. Other shelfware was retired to its position only after it had performed its service and was no longer needed.

For example, I once licensed a program called LinkBot Pro from Watchfire that validates web references. This tool was invaluable in helping me validate links in older versions of Que Publishing’s Official Internet Yellow Pages. I bought the license, used it for the project, and then it became shelfware. This is a good form of shelfware —software that more than provids its value and is then peacefully put out to pasture.

How to Gather Windows SharePoint Services Requirements

Getting good requirements for a SharePoint project is in some ways more critical than for a project that’s based on more widely understood technologies. The fact that SharePoint isn’t widely understood by clients — whether internal or external — means the potential for misunderstandings is much greater. For this reason, it’s more critical to discuss each feature of SharePoint to understand of how the feature works out-of-the-box and to understand how the organization envisions those features. Whether you choose to design and architect your SharePoint technologies solution yourself or decide to work with an outside partner to perform the architecture and design steps, you’ll find that having a foundation in solid requirements makes the development process run smoother and results in a better solution for your business needs. [Article removed from the website]

Harnessing Properties in SharePoint Search

Most users of SharePoint Portal Server rapidly become enamored with the ability to add new fields (containing meta data) to documents in the document library. All of the sudden it becomes possible to associate information to a file beyond the file name that we’ve been limited to since the beginning of the computing era.

Few users, however, have the opportunity to understand how this meta data is used by SharePoint for searching. This leads to problems when users decide that it’s necessary to use SharePoint Portal Server Search to search on information contained in a field that they have added. In this article you’ll learn how SharePoint uses document library fields to create properties that are searchable and how to enable searching on those properties.

Article reposted here: Retro: Harness Properties in SharePoint Search

Creating Artifacts — what you don’t know

[Authors Note: There’s a very interesting discussion brewing about what artifacts are good and what artifacts are bad. Check it out.]

Just as artifacts from ancient times give us information about early man, the documents and presentations you create in IT can give insight into your technology initiatives.

We know relatively little about the humans that were roaming the earth thousands of years ago. But because we have the artifacts they left behind–pots, arrowheads, and so forth–we have a glimpse give us a glimpse into their daily lives and who they were.

Artifacts (documents, Powerpoint presentations, spreadsheets, etc.) also allow a glimpse into the processes that are happening in your IT organization. Learning how to encourage the creation of artifacts is an essential part of managing an IT department.

The power of the artifact

An artifact is anything crafted by human hand that is left behind. This can be a product, a training manual, help documentation, project management documentation, or anything else which is tangible. Most of the time artifacts are documentation or diagrams of some sort but they can also be the finished product or some piece of the finished product.

Developing a data communications strategy

Any data communications proposal can look good on paper until you dissect it by evaluating its reliability, expandability, and complexity.

Whether your organization has two sites or two hundred sites, figuring out how to manage the data communications between those sites can be a real challenge. With a vast array of options, it’s often hard to determine what’s best for your organization. Here are three key evaluation criteria you can use to make the right decisions for your connectivity.


In most cases the reliability of the network is a critical component to how useful it is. Even in organizations where the ability to communicate between sites isn’t core to the business because there are no central databases to be accessed and no real-time need to share information, loss of connectivity is still very disruptive.

Reliability is measured by the frequency, the duration, and the completeness of outages.

Anatomy of a Software Development Role: Development Manager

It is possible to believe that there is nothing left to be done. That all of the roles outlined thus far is all that is needed to make the process work. However, the role of the development manager is critical to the long-term success of the software development team. The role that the development manager plays – particularly when interacting with the project manager – is essential to a continuously improving process. (If you’ve not been following the series, you might want to read Cracking the Code: Breaking Down the Software Development Roles.)

What’s the Development Manager role?

The development manager’s role can be described as “everything else”. Although accurate this description is not very illuminating.

The development management role is the role whose purpose it is to keep the vision on track. This is much like a CEO, who sets the vision for an organization. This of course differs from the COO, who-like a project manager-ensures the day-to-day operations. While it’s the project manager’s goal to get the project to the finish line, it is the Development Manager ‘s responsibility to look ahead to make sure that the finish line is the right finish line to be reaching. While the project management position is a management position, the development manager role is a leadership position. Click here to see how the the Deployment role fits within the full organizational chart.

Read more of the article at

[Author’s Note: I really enjoyed the mental exercise that writing this series brought.  It was a good way for me to clarify my thinking around the various roles in the software development process.  I hope that it can provide a framework for understanding how people fit into the process in your organization. The next series is on Coding standards and starts in just a few weeks.  I’m always happy to get input on what you think should or shouldn’t be in coding standards.]

Recent Posts

Public Speaking