But the graphical elements aren’t the only thing that makes a site good. The look of a site, although very important, is a small piece of the pie. Did someone say pie?

Design is a combination of several elements; having a target audience, great content, stellar information architecture and site accessibility. We can make a site look good, but if the other elements aren’t part of the equation then our visitors will not be happy.

A Target Audience

If you try to serve all your audiences then you don’t serve any of them effectively. Have you ever gone to a site and the home page is a jumbled mess? Most the time this means they have a bad case of the “trying to make everyone happy”, so they try to put information for everyone on the page. What is outcome of doing this? No one can find the information they need. There isn’t any organization, so the site leaves you frustrated and your questions unanswered.

Great Content

Make your content conversational. Have you ever gone to a site and feel disengaged from the site and their purpose? Or needed a doctoral degree to understand what they are trying to say? When reading their content does it sound like an old grant proposal, with a lot of “The candidate”, “The person”, “The Company” phrasing? You wouldn’t talk to a person if they came into your office that way, so why would you write content for your site that way? Instead of saying “The candidate will receive….” say “You will receive..”. Just that little change makes visitors more engaged and feel included in your purpose.

Stellar Information Architecture

Make it easy for visitors to find the information they desire. Have you ever been frustrated when on a site because it is impossible to find answers to your questions? Have you ever been sure that something would be found in one area of the site, to only find it somewhere totally different? Your navigation should be easy to follow. Navigation sets should be grouped together and there should be more than one way to get to content.

Site Accessibility

Make your site accessible to ALL that visit. Have you ever found it difficult to read something on a site because the color of the font? Or seen a flashing “new” animated gif and thought wow that is really distracting? We need to be aware and thinking about accessibility of our site to all visitors. The smallest things can make the biggest difference.

As you can see there are more elements to design than just the graphics. These are all elements we need to think about when creating an excellent web site for ourselves and our customers. It is our responsibility to make our customers aware of these items and help them understand the importance of each. I will spend more time in upcoming posts to go deeper into each of these areas. So look back often for what other goodies I might have to say

When the college web sites launched three years ago – before my time – they were, and remain, Information Architectural tours-de-force. Underpinned by extensive user research and expertise, this was a huge and hugely successful implementation. Students liked the results, faculty liked the results; the web sites work.

The solid evidence base on which these sites’ IAs were constructed surely muted many protests. To be findable, library opening hours do not need a flashing “click here” button on the homepage, it turns out. Remarkably, students will find Financial Aid information perfectly well without an animated rainbow-colored piggy bank bouncing off the sides of the screen.

At their core, the navigation components are built to both reflect and facilitate the ways in which users actually interface with and value information, which does not often map onto what insiders “know” about how things “should” be. Students might not know what a registrar is, but they know that an 8AM clinical phlebotomy lab sounds like a blast, if only they could locate the class schedule… In other words, users have specific tasks in mind, and admiring graphical and verbal embellishment are rarely among them.

As we go mobile, we need another unlearning of what we “know” and an evidence-based relearning of what works.

This time we don’t have tailored user market research, we don’t have outside experts, and we’re not subcontracting any aspect of our mobile project. And the world’s best project manager is not on our team. We need to be creative and resourceful, which means we need to harness and harvest (to mix some timely agricultural and equine metaphors as the sun shines on Keeneland’s 75th fall meeting celebration) whatever tools are available to us to make our mobile sites aesthetically beautiful and structurally solid.

But we also need, I would argue, a “show” to counter what we and others “know” about IA. Because a lot of people know a lot about IA. They know what our users are really looking for. They know that we should probably replace our student sites, the accumulated works of college Web Services professionals and departmental content owners, with a Twitter feed (true story). They know that the web is passé, traffic is down, and iPhone apps are, like, totally where it’s at (true story). Dude, what about an iPhone app that provides up-to-the-minute, 140-character Tweets on #FederalFinancialAidRegulationsAsApplicableToPellGrant-EligibleStudents? But could they present evidence to show any of these trends? No. But Google Analytics can. Or, rather, it could, but it would be lying, and non-evil Google doesn’t lie..

For mobile IA development, Google Analytics and its accumulated two-year System-wide set of visitor data, is a God-send.

Analytics can tell us what our users really are looking for. It can tell us if traffic is faltering, if everyone has an iPhone, and if our current student content is a waste of precious virtualrealestate.

Analytics gives a lot of really interesting answers. It gives a lot of answers, period, some of which may even be useful, actionable answers – provided we ask the right questions. They are only useful if we can then operationalize their implications for IA in a meaningful way.

So over the coming months, I will blog about what Google Analytics can tell us, and can’t, how we do using those data to develop parsimoniously beautiful IAs for our colleges’ mobile presences. Then (or rather, simultaneously) come design, branding, and content.

First up: mobile apps or mobile versions? What we know, and, more usefully, what Google Analytics shows…

Next up, a giant thank you to everyone who attended this event.  I am always surprised at just how many people come out to learn about SharePoint. And I am humbled every time someone comes to hear me speak.

At SharePoint Saturday the Conference – DC I was able to present a full day workshop: SharePoint Branding 101.  This workshop was exciting for me to try and fit in as much branding goodness into 6 hours as I could.  It was certainly a challenge.

During the day we discussed a full range of topics from Requirements Gathering for Branding all the way through to Implementation and Deployment of Features.

Now that we have all had a moment to take a breath and recover a bit from this very full day of branding learning. I wanted to post out a few things for you.  First up are the slides from the presentation.  Hopefully they will help some of you out as you approach projects in the future. (Thanks for the feedback from a few of you I helped already, it certainly makes me happy to share)

SharePoint Branding 101 Presentation

I really enjoyed spending the day with those of you who were able to join my session in DC. I look forward to meeting many more of the SharePoint Branding intrepid over the next few months!

I am sorry for the delay in posting this.  I also wanted to add a quick listing of helpful tools and items I mentioned in the session.

Wireframing:

Balsamiq Mockups – This is a for purchase application, not free

Visio Graphic Stencils – These are a free download

Visio User Interface Stencils – These are for purchase, not free.

SharePoint Design: (both of these are great and a huge undertaking for both of the creators!)

Starter Master Pages Courtesy of Randy Drisgill – A Gigantic Thanks to Randy

SharePoint 2010 CSS Chart Courtesy of Heather Solomon – A Gigantic Thanks to Heather

When creating an instance of a workflow through the SharePoint web interface, you must select one of the base template types, such as the “Approval” or “Collect Feedback” workflow, for the baseline of your workflow instance. When you create a custom workflow through SharePoint Designer, you are not selecting a baseline template for the workflow therefor, in code, the SPWorkflowAssociation.BaseTemplate value for the custom workflow will be null. By verifying the value of this property, it is a good indication that the workflow is custom and, in my case, was created with SPD.

You can further verify the existence of a custom workflow by checking the existence of an “Xoml” reference within the SPWorkflowAssociation.InternalName property. In a typical out of the box workflow, the InternalName property for the workflow association would be something similar to “Approval” or “Collect Feedback”. When custom workflows are created through SPD, there is a set of XML markup files that are created which manage the rules and configuration of the workflow and also tie the workflow to a specific SPList. The InternalName property contains references to this Xoml so by simply searching this property for the existence of “Xoml”, your can be assured that you are working with a custom workflow.

Lastly, another property on the workflow association that warrants mention is the SPWorkflowAssociation.Enabled property. As modifications are made to custom workflows within SharePoint Designer, there is a version history that is maintained for that workflow. As workflow modifications are made and published, previous versions of a workflow are disabled to ensure that only the latest version is executed. As you iterate through the SPWorkflowAssociations related to an SPList or SPContentType, you can appropriately find the most current workflow with the Enabled property.

The following simple code snippet will iterate a SPList and identify the custom workflows:

 1: using System;

 2: using System.Collections.Generic;

 3: using System.Text;

 4: using Microsoft.SharePoint;

 5: using Microsoft.SharePoint.Workflow;

 6: 

 7: namespace SampleWorkflowDiscoveryApp

 8: {

 9:   class Program

 10:   {

 11:     static void Main(string[] args)

 12:     {

 13:       using (SPSite site

 14:                  = new SPSite("http://contoso.com"))

 15:       {

 16:         using (SPWeb web = site.OpenWeb())

 17:         {

 18:           SPList list = web.Lists["TestList"];

 19:           foreach (SPWorkflowAssociation wfAssoc in list.WorkflowAssociations)

 20:           {

 21:             // Not interested in previous 

 22:             // versions of workflows

 23:             if (wfAssoc.Enabled)

 24:             {

 25:               if (wfAssoc.BaseTemplate == null &&

 26:                    wfAssoc.InternalName.Contains("Xoml"))

 27:               {

 28:                 // Identified a custom workflow

 29:                 // Add more logic here...

 30:               }

 31:               else

 32:               {

 33:                 // Out of the box workflow

 34:               }

 35:             }

 36:           }

 37:         }

 38:       }

 39:     }

 40:   }

 41: }

Hopefully this will save you some of the time that I spent locating the best approach for identifying custom workflows.

Enjoy,

Jason

This article is cross posted at my Summit 7 Systems blog.

So why all of the Weird Science? Well, much like Gary and Wyatt, I pieced together a bunch of stuff and made a creation of my own. No, I didn’t create Lisa, but I did create a nifty little something that some of you other admins, devs, and branders might find useful.

Large lists and libraries are becoming more and more common and the issues that come with it are going to be something that all of us will have to overcome. I recently had to troubleshoot a problem with large list throttling on a document library, and needed to see if I could recreate the issue. This sounds simple, get a document library with thousands of documents and create some views and make sure that you have an indexed column to see the difference in your views with filters. Well, I didn’t have the time or desire to create thousands of documents or to upload them, do you?

So I thought hey, there’s bound to be a way to do this with something like a PowerShell script. I began to search and found a few scripts online for uploading documents, but again, I didn’t want to deal with creating the documents to upload. I pinged my good friend and mentor Todd Klindt to see if he maybe had a script already that would do this. He had one that would create list items and shared that with me, which was very helpful in getting this started. I did use it to test the issue with lists, but still needed to work with documents in a library.

So now what? I needed to create something that would create the documents and would also add metadata in columns. I did some research and found that creating list items was a little different than creating files in a document library. I found out using SPFileCollection.Add was what must be used to create items. I found this blog post that showed how to create a new wiki page in a wiki library and modified it some to create a document in a document library.

I took part of the script Todd had given me and part of the script that the other guy had written and used it to test creating multiple documents. As it would turn out, this was the easy part. Below is a script you can use to create a bunch of documents in a library.

   1:  # connect to sharepoint and open the library

   2:  $library = (get-spweb http://portal.s7gear.com/IT/Help).lists["LargeLibrary"]

   3:   

   4:  “Got List…” 

   5:  for ($i=1; $i -le 1000; $i++) 

   6:  # try to add a new item # Try to add a new item 

   7:  {

   8:  [byte[]]$mydata = “Lori Rocks, with help!”.ToCharArray(); # dummydata 

   9:  $item = $library.RootFolder.Files.Add("ItemTitle" + $i + ".doc", $mydata)

  10:  }

This was very cool. Of course, now I had a bunch of documents, but no metadata to work with for list filtering. The $mydata string can be changed to whatever you want the document to contain. Of course, this means it really can only be used for testing, since you can’t create a huge formatted document, but at least you can create a bunch of them!

Now comes the fun part. Adding in metadata. It turns out that using the SPFileCollection.Add method allows you to add the data to the document and title the document, but adding metadata is much more difficult. It apparently includes the ability to create a hash table that can be used for this, but I was unsuccessful in my non-dev attempts to get this to work. So I thought about it and decided that it might be possible to add the metadata after the creation of the document. I didn’t have check out forced on my library, so it should be a fairly simple thing to do, right? Yeah… a dev probably could have done this in their sleep, but not me, oh no, it was a challenge, but one I was willing to accept!

So after repeatedly banging my head on my desk, and bouncing ideas off of Todd (lifesaver!!!!) I was finally able to come up with a solution that would add the metadata to existing documents.

   1:  # connect to sharepoint and open the library

   2:  $library = (get-spweb http://portal.s7gear.com/IT/Help).lists["LargeLibrary"]

   3:  "Got List"

   4:  #SetMetadataforItems

   5:   

   6:  $library.Items|Where-Object {$_.Name -like "ItemTitle1*"}|ForEach-Object{

   7:  $_["Number"]="1"; $_["Indexer"]="1"; $_.Update()}

This is great, right? It would find only those items that matched the title pattern and add the metadata to the appropriate columns. Which is a great little tool. Now, to put it all together:

   1:  # connect to sharepoint and open the library

   2:  $library = (get-spweb http://portal.s7gear.com/IT/Help).lists["LargeLibrary"]

   3:   

   4:  “Got List…” 

   5:   

   6:  for ($i=1; $i -le 1000; $i++) 

   7:  # create new document  

   8:  {

   9:  [byte[]]$mydata = “Lori Rocks, with help!”.ToCharArray(); # dummydata 

  10:  $item = $library.RootFolder.Files.Add("ItemTitle010-" + $i + ".doc", $mydata)

  11:  }

  12:   

  13:  #Add Metadata

  14:  $library.Items|Where-Object {$_.Name -like "ItemTitle010-*"}|ForEach-Object{

  15:  $_["Number"]="010"; $_["Indexer"]="010"; $_.Update()}

With this tool, you can create documents with different titles and metadata. You need only to change the titles and metadata for each series of documents that you want to create and run the script again. In my case, I ran the script 10 times and created 10000 items in a matter of a few minutes, versus the hours it would take to create the documents and upload them. I do recommend using a number with a dash if that is how you choose to name your documents so that you can keep each series separate. Don’t forget if your column is a lookup type of column, you’ll have to make the value of it like: “ID’;#Value”. Where the ID is the id of the value of the item.

I hope this helps those of you out there who may need to build in a large list or library for troubleshooting, branding, or performance testing and evaluation.

Oh, and big thanks to Mike Mukalian (@mmukalian) for keeping me sane during the troubleshooting part, I didn’t go into the details in this post, but he was a great help!

Happy SharePointing!

This post is cross-posted from here.

As I walked in, one of the first issues they bring to me is that when a user goes to a Status List (formerly a KPI list in 2007) and views the details of the list item, it doesn’t show the list in the view below the details. OK, so maybe this is the way it is supposed to be, I think to myself. I’ll be honest, I know the basics of KPI/Status lists, but I don’t work with them all that much, so I wasn’t sure. So I sat down at my computer and fired up my VM, which is at SP1, but not the June 2011 CU and tested it out.

Here’s how I tested. First, I created a simple tasks list in a team site, then I created a few test tasks and set them at various percentages of completion, 10, 50, 100, pick your poison if you are doing this, just do a few and set them all at different percentages. Then I created a new status list. This seems like something easy, but then you look at it and wonder ok what now? So click New, and create a new SharePoint List Based Status Indicator. I titled the indicator as “Good Status” (creative, I know!) and then set it up to be an average of all of the percentages of completion and if the average was 50% then it was yellow, and 100% then it was green, all other things would be red. My average was 63.33333…% so it was a yellow indicator that appeared.

Then I clicked on the status indicator, which would open the details. Lo and behold, there is the list view showing below my status details. It looks like this:

Ok, so now I’m thinking not seeing the list definitely isn’t the default behavior of 2010. I test it again on one of the client’s dev machines, which is also at SP1, but no June 2011 CU applied. Identical behavior.

Ok, so now I’m thinking, this was an upgrade, so maybe it is just something with the upgrade causing it, so we log into the production server, create a NEW site collection, new site, new lists, and what do you know, it doesn’t show the list. Hmm… ok so it is definitely not just an upgrade issue. We begin to troubleshoot those pesky little issues that sometimes cause these weird behaviors. We check the hosts files entries on the servers, they are all set to come back to the local host for those host entries. OK so the next thought is to check out that “wonderful” loopback check, we check all servers, and the host headers are set up in the registries appropriately so that loopback won’t be an issue. I checked all of the logs, there is nothing except the entry where it was clicked, no errors, no nothing.

Now I’m grasping at straws. I start searching to see if anyone else has had this problem and I come up empty handed. Now what? I decided to install the June 2011 CU on my VM and then check, then activate any features that might be activated on their production servers in my VM and check after each one to see where/when it might break. If I didn’t find the culprit, then we’d start finding some more heavy hitters to help with this issue.

So after staring at blue lines across my screen for nearly 2 hours (it takes a REALLY long time to install the June 2011 CU, especially in a VM on a laptop) I finally am able to go in and test the first difference in our environments. Well what do you know, the list I created before now shows no list in the details now. Thankfully I didn’t have to go any further. This is what appeared:

So for those of you who have installed or plan to install the June 2011 CU, this behavior may occur in your environment. I am reporting this to Microsoft and will let you know in comments or updates if there is any response and if there is a fix that is reported. 

Happy SharePointing!

This post is cross-posted here.

But what is a wsp or Solution file and how do we create this.  Most of us who are Designers first and SharePoint people second, might never have heard of a wsp before SharePoint.  Let me explain the advantages to using a Solution file.

Creating a wsp for your SharePoint Branding will allow you:

• Easier ability to troubleshoot site errors. You can turn the feature off and eliminate your branding as the root cause of problems
• Make it Managed Code, which makes our developers happy and allows us to have a versioned copy of our files.
• Easier to Update. Having all your files in one package will give you the ability to more easily make changes and updates.
• Provides a greater sense of control. You can enforce policy around your site branding and even change the behavior around things like new site creation.
• The other big component is where your files are located. Solutions will allow you to place the files for your branding on your server instead of in the content database.  This will help with performance and page load times.

These are just a few of the reasons that we deploy SharePoint branding as a feature.  But what exactly is a feature and how do we create this mysterious thing.  If you are a developer or have a staff of developers you can enlist their help in creating this.

The long and short of it is, that a solution for SharePoint branding is made using Visual Studio.  In order to make this transition you should set up a solution in Visual Studio much like you would if you were writing a web part. 

I have attached a sample wsp and Visual Studio 2010 project file to this post. You can use this as a basic sample for how you might start to set up your very own branding solution. This sample solution is being provided to you in conjunction with Paul Schaeflein, SharePoint MVP. I am not a developer, so I had to enlist some help to properly form this solution file.

Sample Solution

There are some big tips in working with solutions and moving your files into a proper SharePoint 2010 Branding solution. If you are anything like me, you will have worked your initial branding development using SharePoint Designer.  When it comes time to move your files into Visual Studio you will find yourself asking what is the best method.

I have found that simple exporting your files out and importing them into Visual Studio leaves you open to what I affectionately refer to as SharePoint Designer Gobbledygook. (Yes that is my very own fun technical term) SharePoint Designer is a great tool for working with SharePoint branding, but it has a tendency to create issues when it comes to moving your files outside of it. 

My favorite method for moving files from SharePoint Designer into Visual Studio is to simply copy the code out of your files in SPD and move it into a simple text editor like Notepad. Then when I have Visual Studio open I will create blank files and copy my code out of Notepad into these blank files.

Once you have done this you will still want to check for that gobbledygook. This can come in many formats. The most common are hard returns in the files or the insertion of some SharePoint Designer specific file characters in the head tag and !DOCTYPE declarations. This extra information can and will cause problems for you. So you will want to remove this as you find it.

Working with Visual Studio and SharePoint branding can be a bit of a challenge for those without an understanding of basic SharePoint development, but it is not impossible. Once again, I am providing you with a very basic SharePoint branding solution that you can start to see how it works.

Sample Solution

And again, thanks to Paul Schaeflein for helping me out and writing a solution and agreeing to allow me to share it with all of you.

Recently, I needed to produce a deployable SharePoint 2010 solution package for a custom Site Column for a client. This wouldn’t have been an issue except for the fact that it needed to exactly replicate the deployed Site Column down to the GUIDs and field definitions. What I needed was some way for the onsite SP administrators to export the currently deployed Site Columns so that I could replicate them within my environment.

Solution

As a result, I produced a short PowerShell script that, when executed on a server within the farm, will produce a listing of XML files for each of the Site Columns within the designated site. Each of these separate XML files will contain the data that is extracted from the SPField.SchemaXml attribute relating to the Site Column. The script is as follows:

[powershell]
# Output-SPSiteColumns.ps1
# Will output a listing of the Schema XML values for each Site Column within a designated site.
#
# Input Parameters
# URL – The Url of the site to pull Site Columns from
# Site Column – The specific name of the Site Column to output, All to output all Site Columns, or List to see all available Site Columns
# Folder Name (Optional) – A specific folder to output the geenerated XML files to.
#
# SharePoint DLL
[void][System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)

Set-Variable folder -value ‘SiteColumns’

function CreateFolder([string] $folderName)
{
if((Test-Path $folderName -pathType container) -eq $False)
{
Write-Host ‘Generating ‘ $folderName ‘ folder’
New-Item $folderName -type directory
Write-Host “”
}
else
{
Write-Host ‘Folder ‘ $folderName ‘ already exists, not recreating.’
}
}

# Output the SchemaXml of all Site Columns to individual XML files

# Parse out the folder name if it exists.
if($Args[2] -ne $null)
{
$folder = $Args[2]
}

if($Args[0] -ne $null)
{
Write-Host “”
$url = $Args[0]

$site = new-object Microsoft.SharePoint.SPSite($url)
$webFields = $site.rootweb.Fields

$siteColumn = $Args[1]
if($siteColumn -ne $null)
{
if($siteColumn -eq “List”)
{
ForEach ($id in $webFields)
{
Write-Host $id.Title
}
}
elseif($siteColumn -eq “All”)
{
CreateFolder $folder
Write-Host “Producing XML for All Site Columns”
ForEach ($field in $webFields)
{
$title = $field.Title
$title = $title -replace “/”, “-”
$out = $folder + ” + $title + ‘.xml’

$field.SchemaXml | Out-File $out
}
}
else
{
$field = $site.rootweb.Fields[$siteColumn]
if($field -ne $null)
{
CreateFolder $folder
$title = $field.Title
Write-Host ‘Producing XML for the ‘ $title ‘Site Column.’
$title = $title -replace “/”, “-”
$out = $folder + ” + $title + ‘.xml’
$field.SchemaXml | Out-File $out
}
else
{
Write-Host ‘ERROR: Field ‘ $siteColumn ‘ does not exist.’
}
}
$site.Dispose()
Write-Host “”
Write-Host “Completed Successfully”
Write-Host “”
}
else
{
Write-Host “”
Write-Host “ERROR: Please specify a valid Site Column, All, or List to see a listing of available Site Columns.”
Write-Host “”
}
}
else
{
Write-Host “”
Write-Host “ERROR: Missing URL argument”
Write-Host “”
}
[/powershell]

To execute the PowerShell script, there are two required and one optional command line parameters. The execution parameters of the script are as follows:

• URL – The Url for the site that you would like to view the Site Columns for.
• Site Column – The specific name of  the Site Column to export, List for a listing of all available Site Columns, or All for an export of all Site Columns within the site
• Folder Name (Optional) – The folder name which will contain all the Site Column XML export files. By default, these files will be created within a folder named SiteColumns

Using these parameters, the script could be executed based on the following example:

.Output-SPSiteColumns.ps1 http://web.contoso.com/sites/testsite All SiteColumnsExport

Code

You can download the script code file which you to examine and modify as needed. As a standard disclaimer, I assume no responsibility for the execution of this script within your environment.

Enjoy,

Jason

*This item is cross posted at my Summit 7 System blog.

This is a continuation of an earlier post relating to the architecture and configuration of a SharePoint 2010 development environment which can be found here. In the original discussion, I started detailing out the concepts and requirements for single and multiple server development environments as shown in the following diagram:

As a quick review, the single and multiple server development environments each have their own unique purpose. Single server environments are ideal when there is a need to develop a quick proof of concept or to develop out a simple solution that does not require access to advanced functionality such as multiple service applications or access to full SQL Server instances. Multiple server development farms are ideal for more advanced situations primarily because they allow for the distribution of functionality across servers, which leads a more responsive environment. Having a single server environment handle the resource intensive demands of a full SQL Server instance, a SharePoint Web Front End, SP Search indexes, and multiple SP Service Applications all within one machine, could bring development times to a crawl because these applications would be competing for the same resources.

Ultimately, the decision of which development environment to begin with is a personal decision and should be chosen based on the requirements gathering and solution discovery phases of the program.

Multi-Server IT Pro Farm

Outside of the development of a complex custom solution with the use of tools such as Visual Studio, there can be times when the development of a solution aligns more with that of an IT Pro task. It seems more and more common that I will be involved in the development of a solution that is along the lines of an architectural solution as opposed to a pure custom coded solution. It is because of this that I have a specific need to have an IT Pro based environment.

What differentiates my IT Pro farm from my Development farm? Basically, it’s what’s not there that makes it necessary. Within my development specific environments, there are additional tools that are installed such as Visual Studio 2010, FxCop, CKS Dev. Tools, etc. The IT Pro environment is void of all these extra tools. Perhaps, the only tooling application that should remain in this environment would be the SQL Server management tools, not to provide access to the SP content databases but more to provide the ability to create databases that could be used with the Business Connectivity Servers application. Additionally, the installation of applications like Visual Studio 2010 include not only the development IDE but also a number of supporting framework packages, SDKs, and other additional software that wouldn’t normally be available within a SP Production environment.

By removing as many of these tools as technically feasible, the IT Pro environment provides a solid foundation to develop solutions by utilizing out of the box functionality and SharePoint Designer 2010.

Multi-Server Integration/Quality Assurance Farm

Much like the Multi-Server IT Pro environment, the Integration/Quality Assurance Farm should be void of any supporting development applications or SDKs that would not normally be found within a production SharePoint environment. Now, it’s understood that actual production environments can come in various shapes and sizes. Although there are many variations to the architecture that are possible, as a solution developer, the accessibility of SharePoint’s multiple capabilities will, in general, operate in the two server IT Pro farm similar to how they would within a fully load balanced production implementation.

This clean and sterile environment will allow for the testing of solutions without the additional configuration settings that could have been applied during development. Though I’m sure every developer takes extra precautions to ensure that all configuration settings for a solution are well documented in order to replicate the deployment without issue, there will inevitably be the case where this process fails and it is the role of this development environment to expose these flaws.

As mentioned before, the Integration and QA environment can, and most likely will, be hosted within a set of virtual machines. That said, this environment should be hosted in a central location which could be available to anyone within the development team, depending on the size of the team. This would serve two purposes. First, a centrally hosted integration environment will allow for better integration with other efforts that might be going on simultaneously. By following the previous deployment process of developing your solutions within the multi server development or IT Pro farms, the solutions deployed here should be relatively stable and will provide the first opportunity for developers to have their components interact with other solutions.

Second, having a centrally hosted integration environment allows for tighter control over the configuration. This environment should have a set of administrators designated to this farm and to manage access permissions and overall configuration. With this, you can ensure that inappropriate areas of your system, such as the web.config file, are not being modified without the proper procedures. Additionally, in many workspaces, it would be common to have the build out and configuration of the Integration and QA farm in a scripted format so that the tear down and rebuild of the environment can be readily repeated in the event that a solution or configuration breaks the system.

Conclusion

In the end, the architecture and configuration of a developer’s environment is of personal preference. Hopefully, I’ve been able to shed a little light into how I operate on a day to day basis and I welcome hearing about the advantages of your environment.

Thanks,

Jason

This entry is cross-posted at http://summit7systems.com/blogs/jasoncribbet.